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Abstract 


This  document  provides  a background  discussion  of  product  data,  describes  the  con- 
cept of  IGES  (Initial  Graphics  Exchange  Specification)  application  protocols,  specifies 
the  technical  content  of  an  IGES  application  protocol,  describes  a validation  methodol- 
ogy for  these  application  protocols,  and  provides  guidelines  for  the  implementation  of 
an  IGES  application  protocol.  A key  conclusion  of  the  background  discussion  of 
product  data  is  that  IGES  application  protocols  must  be  developed  in  order  to  achieve 
consistent  and  reliable  exchanges  of  product  data  within  specified  application  areas. 

The  technical  content  of  an  IGES  application  protocol  includes  a conceptual  informa- 
tion model  for  the  application  area  with  its  supporting  documentation,  an  application 
protocol  format  specification  with  a protocol  usage  guide,  and  a set  of  application 
protocol  format  test  cases.  These  test  cases  must  be  used  in  concert  with  a well-defined 
testing  methodology. 

Since  no  complete  IGES  application  protocols  currently  exist,  this  document  describes 
a current  implementation  of  an  application  protocol  process  that  is  based  on  a partial- 
ly complete  application  protocol.  The  document  also  includes  a specific  example  of  a 
simple  application  protocol  that  meets  the  technical  content  requirements. 


Key  words:  application  validation;  CAD  data  exchange;  computer-aided  design  and 
drafting;  data  exchange  standards;  data  translation  quality  assurance;  data  translators; 
IGES;  IGES  application  protocols;  information  management;  validation  of  data  trans- 
lators 
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1.  Introduction 


A major  objective  of  many  users  of  CAD/CAM  equipment  is  the  effective  exchange  of 
data  throughout  the  life  cycle  of  products.  This  may  include  the  use  of  computer 
readable  data  sets  describing  the  products,  their  assemblies,  subassemblies,  and  the 
product  support  data.  A central  issue  is  the  exchange  of  digital  representations  of 
product  data  in  various  forms:  illustrations,  2-D  drawings,  3-D  edge-vertex  models,  sur- 
faced models,  solids  models,  and  complete  product  models. 

Throughout  industry,  an  increasing  number  of  computer-aided  design  systems  are 
being  used  in  all  phases  of  design,  analysis,  manufacturing,  and  testing  of  products. 
Over  one  hundred  vendors  offer  CAD  systems,  and  most  industries  have  already  com- 
mitted themselves  to  working  in  heterogeneous  CAD  environments. 

Even  with  the  great  variety  of  CAD  systems  available  today,  no  single  CAD  system  pos- 
sesses the  depth  and  breadth  of  capabilities  to  satisfy  the  needs  of  all  users  for  all  ap- 
plications. Because  of  this,  users  tend  to  purchase  a variety  of  CAD  systems,  each 
selected  to  support  a particular  application.  Complexity  is  introduced  into  the  use  of 
CAD  systems  when  product  data  must  be  exchanged  between  different  business  units 
and  outside  participants  at  major  milestones  of  a project;  design  to  engineering,  en- 
gineering to  manufacturing,  manufacturing  to  inspection,  prime  contractor  to  sub- 
contractor, or  vendor  to  customer. 

There  is  a requirement  in  the  normal  course  of  business  to  be  able  to  exchange  the  digi- 
tal product  models  and  drawings  that  are  developed  on  one  system  with  another  dis- 
similar system.  This  may  be  for  the  internal  transfer  of  product  data  or  for  the  purchase 
of  product  data  from  external  sources.  The  exchange  of  digital  product  models  is  ex- 
pected to  become  as  commonplace  in  the  1990’s  as  the  exchange  of  paper-based  en- 
gineering drawings  is  today.  In  order  to  effectively  integrate  CAD  technology,  industry 
requires  comprehensive  and  reliable  data  exchange  mechanisms. 


1.1  Scope 


This  document  contains  a background  discussion  of  product  data,  specifies  the  techni- 
cal content  for  an  IGES  (Initial  Graphics  Exchange  Specification)  application  protocol, 
describes  a validation  methodology  for  IGES  application  protocols,  and  provides 
guidelines  for  the  use  of  IGES  application  protocols. 

Since  no  complete  IGES  application  protocols  currently  exist,  this  document  describes 
a current  implementation  of  an  application  protocol  process  that  is  based  on  a partial- 


1 


ly  completed  application  protocol.  The  document  also  includes  a specific  example  of 
a simple  application  protocol  that  meets  the  technical  content  requirements. 


1.2  Background 


IGES  is  a neutral  representation  format  for  the  exchange  of  product  definition  data  be- 
tween CAD  systems.  Since  the  release  in  1980  of  the  first  version  of  IGES,  the 
IGES/PDES  (Product  Data  Exchange  Specification)  Organization  has  added  increas- 
ingly sophisticated  data  constructs  to  the  IGES  specification.  As  the  capabilities  of 
IGES  have  been  expanded  to  accommodate  more  applications,  the  specification  has 
become  more  pliable.  Some  of  these  changes  have  added  to  the  complexity  and  am- 
biguity of  the  specification,  and  this  has  increased  the  difficulty  of  using  IGES  effec- 
tively. 

At  present,  no  vendor  supports  all  of  the  entities  in  the  entire  specification  with  their 
IGES  processors.  Each  vendor  has  implemented  a subset  of  the  specification  which 
best  matches  the  salient  capabilities  of  their  CAD  system.  Hence,  there  is  only  limited 
IGES  entity  correspondence  between  the  processors  of  dissimilar  CAD  systems  and 
no  definition  for  conformance  to  the  IGES  specification.  This  situation  has  forced 
users  to  limit  their  data  exchanges  to  only  those  entities  that  are  uniformly  supported 
by  both  the  sending  and  receiving  systems. 

Implementations  of  IGES  translators  for  different  CAD  systems  continue  to  be  uneven 
in  quality  and  capability.  Additionally,  the  majority  of  industries  have  not  adopted  the 
level  of  information  control  that  is  required  for  successful  exchanges  of  CAD  informa- 
tion using  IGES.  IGES  application  protocols  are  being  developed  as  a mechanism  to 
address  these  problems. 
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2.  Fundamental  Concepts 


In  order  to  successfully  use  IGES  for  CAD  information  exchanges,  organizations  must 
have  well-defined  technical  information  management  plans  and  documented  proce- 
dures for  creating,  delivering,  and  maintaining  technical  information  in  digital  form. 
This  documentation  must  include  the  standardized  modeling  conventions  by  which 
product  information  is  created  and  the  protocol  for  precisely  transferring  that  informa- 
tion via  the  IGES  format. 

A protocol  is  a set  of  conventions  or  rules  that  govern  the  operation  of  functional  units 
to  achieve  communication.  [1]  The  concept  of  IGES  application  protocols  provides  a 
formal  procedure  for  specifying  neutral,  IGES-based,  application  specific  formats.  The 
procedure  for  developing  application  protocols  involves  identifying  the  information  re- 
quirements of  an  application  area  and  documenting  them  in  an  information  model. 
The  information  model  is  then  used  to  select  the  IGES  constructs  for  representing  the 
required  information. 


2.1  Product  Data  as  a Resource 


Industrial  users  must  be  able  to  deal  with  digital  product  data  in  six  generic  applica- 
tions: 

- Internal  transfer  of  product  data; 

- Data  transfer  from  design  systems  to  product  support  systems; 

- Acquisition  of  new  manufactured  parts  and  systems; 

- Competitive  reprocurement  of  spares; 

- Purchase  of  data  for  a product;  and 

- Archival  storage  of  parts  and  assembly  data. 


Digital  product  data  is  becoming  an  important  consideration  in  contractual  relation- 
ships for  the  purchase  of  manufactured  parts,  assemblies,  or  whole  systems  and  projects. 
Numerous  internal  transfers  of  product  models  are  found  in  R&D,  prototype  design, 
overhaul,  and  retrofit  planning,  and  each  is  a candidate  for  digital  exchange  in  the  im- 
mediate future. 

The  economic  significance  of  digital  product  data  is  easily  seen  from  these  examples. 
Efficiency,  accuracy,  and  lead  time  improvements  are  all  substantially  enhanced  by 
providing  the  methods  for  the  reliable  interchange  of  digital  product  data. 
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Two  terms  will  be  used  for  classifying  data:  product  definition  data  and  product  data. 
Product  Definition  Data  denotes  the  totality  of  data  elements  that  completely  define 
the  product.  Product  definition  data  includes  the  geometry,  topology,  relationships, 
tolerances,  attributes,  and  features  necessary  to  completely  define  a component  part 
or  an  assembly  of  parts  for  the  purposes  of  design,  analysis,  manufacture,  test,  and  in- 
spection. Product  Data  is  more  broadly  defined  than  Product  Definition  Data.  Product 
data  includes  all  of  the  product  definition  data  plus  a larger  class  of  data  elements  neces- 
sary to  fully  support  the  product  for  all  applications  over  its  expected  life  cycle. 


2.2  User,  Implementor,  and  Purchaser  Views  of  Product 
Definition  Data 


The  creation,  exchange,  and  archival  storage  of  product  definition  data  in  the  form  of 
digital  data  sets  can  be  viewed  from  three  perspectives:  the  User,  the  Implementor,  and 
the  Purchaser.  In  some  cases,  different  units  within  the  same  organization  may  hold 
each  of  the  perspectives.  In  other  cases,  each  of  the  perspectives  may  be  held  by  in- 
dividual organizations  that  have  a contractual  relationship. 


2.2.1  User  Perspective 


The  User  perspective  is  the  view  held  by  an  end-user  of  the  product  definition  data 
(PDD).  End-users  have  specific  requirements  for  the  structure  and  content  of  PDD. 
These  requirements  are  a function  of  the  end-user’s  discipline  and  application  area. 
An  end-user  of  PDD  will  be  supporting  a certain  discipline,  such  as  Mechanical  or 
Electrical,  and  will  be  working  within  a certain  application  area,  such  as  Drafting  or 
Numerical  Control  Machining.  The  end-user  will  also  have  an  application-based  view 
of  the  information  requirements  through  the  use  of  application  specific  terminology 
and  rules. 

To  understand  the  User  perspective  of  PDD,  it  is  necessary  to  carefully  consider  the 
current  environment  of  hardcopy  engineering  drawings.  In  the  paper-based  environ- 
ment, the  official  PDD  for  any  of  the  disciplines  exists  as  drawings  that  give  the  product 
definition  data  as  prepared  by  the  Drafting  application  area.  Actually,  these  drawings 
are  only  part  of  the  PDD  that  is  necessary  to  support  the  needs  of  the  end-user’s  dis- 
cipline. 

Currently,  each  end-user  must  perform  an  application-based  interpretation  of  the 
drawing,  extract  the  available  information  for  the  receiving  application  area,  and  create 
the  missing  information  that  is  necessary  to  satisfy  the  end-user’s  information  require- 
ments. 
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One  deficiency  of  paper-based  PDD  (i.e.,  drawings)  is  that  in  most  cases  each  end-user 
is  required  to  repeatedly  perform  an  interpretation,  extraction,  and  augmentation  of 
an  incomplete  set  of  product  definition  data.  These  repeated  end-user  actions  result 
in  more  incomplete  paper-based  PDD. 

Initial  attempts  at  preparing  digital  PDD  sets  were  aimed  at  providing  all  of  the  infor- 
mation that  was  represented  on  the  paper  drawing.  However,  in  the  preparation  of  the 
digital  PDD  sets,  information  was  lost,  and  end-users  were  forced  to  perform  the  same 
interpretation,  extraction,  and  augmentation  of  the  information  contained  in  the  data 
sets  as  had  been  necessary  for  the  paper  drawings. 

Key  concerns  of  users  of  digital  PDD  are:  1)  that  the  requirements  for  data  structure 
and  content  are  well-defined  and  stable;  2)  that  reliable  systems  and  software  to  use 
the  data  are  available,  and  3)  that  the  data  are  prepared  and  read  completely  and  cor- 
rectly. In  order  for  digital  PDD  sets  to  be  a valid  replacement  for  paper-based  PDD, 
the  information  contained  in  any  digital  PDD  set  must  be  at  least  as  complete  as  the 
information  on  the  paper  drawing.  The  other  perspectives  discussed  in  this  section  will 
rely  on  this  conclusion. 


2.2.2  Implementor  Perspective 


The  Implementor  perspective  is  the  viewpoint  held  by  an  individual  who  develops  sys- 
tems and  software  for  Users  to  employ  in  producing  and  reading  digital  PDD.  Im- 
plementors strive  to  provide  systems  and  software  that  meet  the  end-user’s  needs  for 
producing  and  utilizing  digital  PDD. 

In  order  for  the  Implementor  to  develop  systems  and  software  to  produce  and  read 
digital  PDD,  the  implementation  requirements  for  the  structure  and  information  con- 
tent of  the  digital  PDD  sets  must  be  given  in  a well-defined  and  stable  form.  These  im- 
plementation requirements  must  be  based  on  providing  application-based  views  of  a 
complete  set  of  information  that  describes  the  product  for  a certain  discipline(s). 

The  Implementor  must  provide  the  User  a set  of  instructions  for  using  the  systems  and 
software  appropriately  so  that  complete  and  correct  digital  PDD  sets  can  be  produced. 
Users  that  receive  digital  PDD  sets  through  an  exchange  must  be  able  to  read  them 
with  Implementor  developed  systems  and  software  with  the  assurance  that  the  data  sets 
were  correctly  prepared  using  the  Implementor-supplied  instructions. 
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2.2.3  Purchaser  Perspective 


The  Purchaser  perspective  is  the  viewpoint  held  by  an  individual  or  organization  that 
must  purchase  digital  PDD  sets.  The  Purchaser’s  primary  requirement  is  that  the  PDD 
sets  contain  a complete  set  of  information  that  describes  the  product  for  a certain  dis- 
cipline and  provides  support  for  an  application-based  view  of  the  information.  These 
PDD  sets  will  have  been  produced  by  Users  with  Implementor  developed  systems  and 
software  according  to  the  Implementor-supplied  instructions. 

The  Purchaser  must  be  sure  that  the  received  PDD  sets  were  completely  and  correct- 
ly prepared  by  the  Users.  Also,  the  Purchaser  must  be  sure  that  the  Implementor  sup- 
plied systems  and  software  have  the  capability  to  correctly  produce  and  read  the  digi- 
tal PDD  sets.  In  addition,  the  Purchaser  requires  that  User  produced  PDD  sets  can  be 
placed  in  long-term  archival  storage  for  future  retrieval  and  use  with  Implementor 
developed  systems  and  software. 


2.2.4  Summary 


In  summary,  the  User  must  be  able  to  correctly  produce  and  read  digital  PDD  accord- 
ing to  the  information  requirements  of  the  discipline  and  its  associated  application 
areas.  The  User  must  depend  on  Implementor  developed  systems,  software,  and 
documentation  to  produce  and  read  digital  PDD.  The  Implementor  must  provide  sys- 
tems and  software  according  to  a well-defined  and  stable  set  of  implementation  re- 
quirements. The  Purchaser  must  be  able  to  acquire  digital  PDD,  produced  by  Users 
with  Implementor  developed  systems,  software,  and  documentation  for  use  by  other 
end-users  or  long-term  archival  storage.  The  Purchaser  must  depend  on  both  Users 
and  Implementors  for  acquiring  complete  and  correct  digital  PDD  sets. 

Finally,  the  structure  and  information  content  of  digital  PDD  sets  must  be  sufficient  to 
completely  describe  the  product  for  a certain  discipline(s)  and  must  provide  support 
for  an  application-based  view  of  the  information.  The  implementation  requirements 
for  systems  and  software  to  produce  and  read  digital  PDD  must  be  based  on  a well- 
defined  and  stable  information  model.  Users  and  purchasers  require  comprehensive 
methods  for  ensuring  that  digital  PDD  is  produced  according  to  a well-defined  set  of 
requirements. 


2.3  Concept  of  IGES  Application  Protocols 


Information,  either  in  the  form  of  a sentence  or  in  the  form  of  a digital  product  model, 
consists  of  syntax  and  semantics.  The  IGES  specification  defines  the  basic  syntax  and 
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core  semantics  of  the  representation  format.  In  order  to  ensure  complete  and  reliable 
information  exchange  within  a specified  application  area,  the  application  specific  data 
structures  and  semantics  must  also  be  documented  and  controlled.  IGES  application 
protocols  (APs)  are  a formalized  methodology  for  defining  this  semantic  content  and 
the  mappings  to  the  data  structures  of  IGES. 

Application  protocols  allow  the  definition  of  logical  subsets  of  IGES  and  their  usage, 
as  well  as  providing  a mechanism  for  validating  implementations.  The  use  of  an  ap- 
plication protocol  for  the  exchange  of  product  information  provides  a mechanism  for 
participating  agencies  to  agree  on  the  types  of  information  to  be  exchanged  and  to 
employ  corresponding  information  control  procedures. 

The  key  concept  of  application  protocols  is  to  explicitly  link  the  application  area’s  in- 
formation content  to  the  entities  and  data  structures  to  be  exchanged.  The  procedure 
for  developing  application  protocols  involves  identifying  the  information  requirements 
of  an  application  area  and  documenting  them  in  an  information  model.  This  applica- 
tion reference  model  is  then  used  to  select  the  corresponding  constructs  of  the  stand- 
ard for  representing  the  required  information. 

The  components  of  an  IGES  AP  are:  1)  an  application  protocol  information  model,  2) 
an  application  protocol  format  specification  with  a protocol  usage  guide,  and  3)  a set 
of  application  protocol  test  cases.  These  test  cases  must  be  used  in  concert  with  a well- 
defined  testing  methodology.  The  application  protocol  format  consists  of  a "subset"  of 
IGES  entities  including  the  restrictions  on  the  global,  directory  entry,  and  parameter 
data  section  field  values,  and  a detailed  guide  for  the  use  of  each  IGES  entity  in  the 
"subset"  in  carrying  information  from  the  conceptual  information  model. 


7 


3.  IGES  Application  Protocols 


Experience  shows  that  when  the  IGES  format  alone  is  used  for  the  exchange  of  product 
definition  data,  a wide  range  of  entity  types  are  usually  required  to  convey  the  infor- 
mation for  an  application  area.  Vendor  IGES  processors  implement  subsets  of  the 
IGES  specification  and  express  the  user’s  information  in  these  IGES  entities.  Invariab- 
ly there  is  a mismatch  between  the  entities  implemented  in  a preprocessor  and  those 
implemented  in  a postprocessor  of  a different  system.  In  addition,  the  wide  range  of 
IGES  entities  used  by  different  processors  makes  translator  implementation  an  open 
ended  task. 

Product  information  is  usually  encoded  differently  by  IGES  processors,  and  this  results 
in  the  loss  of  some  of  the  information  content  of  the  original  data  files.  It  is  necessary 
and  desirable  to  exchange  the  intended  information  content  and  not  just  an  IGES  data 
set.  Finally,  experience  suggests  that  full  and  functional  information  exchange  for  any 
application  area  will  not,  in  general,  be  accomplished  by  simply  abutting  the  vendor 
supplied  IGES  processors  of  different  CAD  systems. 

IGES  application  protocols  can  help  solve  the  above  problems  and  accomplish  the  suc- 
cessful exchange  of  product  definition  data  for  a specific  application  area.  Because  ap- 
plication protocols  are  based  on  information  engineering  techniques,  application 
protocols  can  be  said  to  allow  the  exchange  of  "information,"  while  the  use  of  IGES 
alone  allows  only  the  exchange  of  "data." 

An  IGES  AP  describes  the  information  content  that  is  expected  to  be  encountered  in 
the  application  area,  identifies  the  mappings  of  the  information  content  into  its  repre- 
sentation by  particular  IGES  entities  and  constructs,  and  describes  the  restrictions  and 
conventions  to  be  observed  in  the  use  of  the  supporting  IGES  entities. 


3.1  Process  for  Developing  IGES  Application  Protocols 


The  first  step  in  specifying  how  an  application  area  can  exchange  its  product  definition 
in  a heterogeneous  computer  environment  is  to  define  the  information  content  to  be 
exchanged.  The  definition  of  information  requirements  must  be  done  independently 
of  any  computer  system  or  product  data  format.  The  information  content  can  be 
described  by  the  use  of  a conceptual  information  model.  The  conceptual  information 
model  must  be  developed  by  an  analysis  of  the  information  that  is  required  to  support 
the  application  area  of  interest.  When  the  conceptual  information  model  has  been 
produced,  it  must  be  validated  conceptually  as  well.  This  validation  must  be  done  using 
the  information  model  and  all  of  its  supporting  documentation. 
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The  second  step  in  defining  an  IGES  AP  is  to  specify  the  AP  format,  i.e.,  how  the  in- 
formation content  from  the  conceptual  information  model  is  to  be  carried  by  a subset 
of  IGES  entities.  The  many  options  for  the  use  of  the  entities  within  this  subset  must 
be  restricted  so  that  only  one  method  is  available  for  carrying  each  element  of  infor- 
mation from  the  conceptual  information  model.  The  set  of  IGES  entities  and  the 
necessary  restrictions  on  the  global,  directory  entry,  and  parameter  data  section  field 
values  must  be  determined  by  using  the  conceptual  information  model  as  a basis. 

The  third  major  step  in  this  process  is  to  develop  and  document  a set  of  AP  test  cases. 
The  test  cases  must  successfully  implement  all  of  the  information  content  of  the  accom- 
panying conceptual  information  model.  These  test  cases  will  be  used  to  validate  the 
proposed  IGES  AP  and  trial  implementations  of  IGES  AP  processors. 


3.2  Required  Technical  Content  of  an  IGES  Application  Protocol 


An  IGES  application  protocol  includes  a conceptual  information  model,  an  AP  format 
specification  with  a protocol  usage  guide,  and  a set  of  test  cases.  The  AP  format 
specification  must  consist  of  a "subset"  of  IGES  entities,  including  the  restrictions  on 
the  global,  directory  entry,  and  parameter  data  section  field  values,  and  a detailed  guide 
for  the  use  of  each  IGES  entity  in  the  "subset"  in  carrying  information  from  the  con- 
ceptual information  model.  An  example  of  a simple  AP  with  each  of  these  components 
is  included  in  Appendices  B.l  - B.3  of  this  document. 

An  issue  in  the  use  of  IGES  AP  formats  is  whether  the  formats  must  be  "restrictive". 
The  notion  of  restrictive  AP  formats  means  that  a conforming  file  is  allowed  to  contain 
only  the  IGES  entities  that  are  identified  to  carry  the  required  information.  Thus,  the 
notion  of  restrictive  AP  formats  would  not  allow  any  other  entities,  e.g.,  "volunteer"  en- 
tities to  be  included  in  an  AP  format  file. 

Considerable  experience  with  the  use  of  IGES  translators  for  product  definition  ex- 
change suggests  that  difficulties  will  be  encountered  if  the  AP  formats  are  not  restric- 
tive. Difficulties  such  as  translator  failure  and/or  loss  of  information  may  be  en- 
countered if  the  software  units  are  forced  to  deal  with  IGES  entities  not  within  their 
capabilities. 

The  current  consensus  of  the  IGES/PDES  AVM  Committee  is  that  the  AP  formats  will 
not  be  completely  restrictive.  The  consensus  position  is  that:  additional  IGES  entities, 
not  in  the  AP  format,  which  do  not  detract  from  the  completeness  or  correctness  of  the 
information  contained  in  the  AP  format,  may  be  included  in  an  AP  format  file. 

However,  none  of  the  additional  IGES  entities  may  point  to  or  be  pointed  to  by  en- 
tities that  carry  information  for  the  AP  format.  This  requirement  is  to  ensure  that 
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software  which  is  intended  to  read  files  in  a particular  AP  format  can  correctly  process 
the  files  by  completely  ignoring  any  entities  which  are  not  part  of  the  AP  format. 


3.2.1  Conceptual  Information  Model 


The  conceptual  information  model  is  called  the  Application  Protocol  Information 
Model  (APIM)  and  will  consist  of  at  least  two  models,  the  Application  Reference 
Model  (ARM)  and  Application  IGES  Implementation  Model  (AIIM).  The  ARM 
documents  the  information  requirements  of  the  subject  application  and  provides  the 
baseline  from  which  candidate  format  implementation  models  are  developed. 

A valuable  intermediate  model  is  an  Application  Implementation  Model  (AIM).  The 
AIM  describes  the  explicit  identifiers  that  will  be  required  for  manipulating  the  product 
definition  data  for  the  subject  application.  The  concluding  model  is  the  AIIM,  which 
shows  how  the  information  content  from  the  ARM  is  to  be  carried  by  a subset  of  IGES 
entities. 

A rigorously  defined  package  of  supporting  documentation  must  be  provided  with  the 
completed  conceptual  information  model.  This  package  must  be  used  in  the  validation 
of  the  model  and  therefore  must  consist  of  the  following: 


a.  The  information  model  must  be  provided  in  one  of  the  approved  informa- 
tion modeling  languages,  NIAM,  IDEF1X,  or  Express.  The  PDES  project  has 
done  modeling  work  in  all  of  these  languages  and  has  designated  Express  as  the 
documentation  language  for  the  integrated  models. 

b.  The  information  model  must  be  provided  with  detailed  definitions  for  all  of 
its  objects  (for  NIAM)  or  entities  (for  IDEF1X).  This  documentation  must  also 
be  supplied  for  a model  in  the  Express  language.  A detailed  glossary  of 
acronyms  and  abbreviations,  and  a detailed  list  of  the  assumptions  that  are  in- 
herent in  the  model  must  be  provided.  This  glossary  must  be  easily  under- 
standable by  an  expert  from  the  application  area  under  validation. 

c.  The  constraints  (for  NIAM  or  Express)  and  business  rules  (for  NIAM  and 
IDEF1X)  must  be  detailed  either  in  the  model  itself  or  in  additional  support- 
ing documentation.  The  constraints  and  business  rules  must  include  the 
relationships  between  the  objects  or  entities  in  the  information  model. 
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3.2.2  Application  Protocol  Format  Specification 


The  application  protocol  format  specification  includes  the  list  of  required  IGES  entity 
types,  the  restrictions  on  the  IGES  entities,  and  the  usage  guide  for  the  AP.  The  AP 
format  must  be  based  explicitly  on  the  conceptual  information  model.  The  IGES  en- 
tity list  and  usage  guide  must  include  the  restrictions  on  the  global,  directory  entry,  and 
parameter  data  section  field  values. 

An  AP  format  specification  must  use  IGES  entities  that  exist  in  the  current  IGES 
specification  where  possible.  It  is  permissible  to  specify  "gray  page"  (IGES  Version  4.0; 
Appendix  J,  Untested  Entities  [2])  entities  for  preliminary  APs.  New  entities  can  be 
defined  for  an  AP  only  where  there  is  no  existing  IGES  entity  that  can  be  used  to  carry 
the  necessary  information.  The  IGES  entities  selected  for  use  in  the  AP  format  must 
be  selected  so  as  to  minimize  the  size  of  resulting  files.  This  means  that  the  "simplest" 
IGES  entity  should  be  selected  when  there  is  more  than  one  possible  choice. 

As  part  of  an  AP  format  specification,  a detailed  "protocol  usage  guide"  must  be 
developed  for  the  users  and  implementors  of  the  AP  format.  This  usage  guide  must 
specify  in  detail  which  IGES  entity(s)  from  the  subset  is  to  be  used  to  represent  each 
element  of  information  from  the  conceptual  information  model.  An  AP  information 
mapping  table  must  be  included  as  a summary  of  these  specifications.  A sample  AP 
information  mapping  table  for  some  possible  Mechanical  Drafting  Application 
Protocol  information  requirements  is  shown. 


Information  Mapping  Table  for  a 
Mechanical  Drafting  Application  Protocol 


Conceptual  Information  Model’s 
Information  Requirement 

Drawing  Format 


Feature  Control  Frame 


Application  Protocol’s  IGES 

EnmkiRequired 

302/402  Associativity  Definition  and  Instance 
consisting  of: 

110  Line 

212  General  Note 

302/402  Associativity  Definition  and  Instance 
consisting  of: 

102  Composite  Curve 
110  Line 

212  General  Note 
214  Leader 
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APPLICATION 

PROTOCOL 

INFORMATION 

MODEL 

— i- 

IGES 

APPLICATION 

PROTOCOL 

FORMAT 


MAPPING  OF  INFORMATION  FROM  AN  INFORMATION 
MODEL  INTO  AN  APPLICATION  PROTOCOL  FORMAT 


Figure  t 


This  mapping  of  information  from  the  information  model  to  the  IGES  entities  is  rep- 
resented in  Figure  1.  The  top  pane  of  the  diagram  represents  the  APIM,  and  the  lower 
pane  represents  the  AP  format  with  its  selected  entities  and  data  structures.  The  ar- 
rows represent  the  mappings.  The  usage  guide  makes  explicit  these  mappings  between 
the  application  information  content  and  the  constructs  of  the  AP  format. 


3.2.3  Set  of  Test  Cases 


A set  of  test  cases,  containing  examples  from  the  application  area,  must  be  included. 
These  test  cases  must  successfully  implement  all  of  the  information  content  of  the  ac- 
companying conceptual  information  model  using  the  IGES  entities  in  the  AP  format. 
The  test  cases  must  correctly  implement  the  syntax  and  restrictions  of  the  AP  format 
according  to  the  usage  guide. 
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The  documentation  for  the  test  cases  must  include  the  following: 

a.  the  objectives  of  the  test  case  and  a description  of  the  data  contained  within 
the  test  case; 

b.  the  expected  results  of  the  test  case; 

c.  a pictorial  representation  of  the  test  case  data; 

d.  the  evaluation  criteria  and  variance  bounds; 

e.  a script  file  for  preprocessor  testing,  and 

f.  an  IGES  file  for  postprocessor  testing. 

3.3  Application  Protocol  Validation 

The  AVM  (Application  Validation  Methodology)  Committee  of  the  IGES/PDES  Or- 
ganization is  responsible  for  developing  procedures  for  the  application  validation  of 
IGES  translators  and  the  translation  process.  As  part  of  these  duties,  the  AVM  Com- 
mittee is  charged  with  reviewing  and  approving  proposed  IGES  APs.  This  committee 
will  only  approve  those  candidate  APs  that  have  met  all  of  the  technical  content  re- 
quirements, specified  in  Section  3.2,  and  the  success  criteria  of  the  validation  methodol- 
ogy, described  in  Section  3.3.1. 

The  AVM  Committee  will  not  perform  a detailed  validation  of  the  information  con- 
tent of  the  candidate  AP.  The  detailed  validation  of  the  AP  information  content  must 
be  performed  by  the  IGES/PDES  technical  committee  that  is  responsible  for  develop- 
ing the  AP.  Those  organizations  planning  to  implement  an  AP  must  validate  the  AP’s 
correspondence  with  their  information  requirements  and  must  develop  the  necessary 
digital  data  quality  assurance  procedures. 

The  AVM  Committee  will  perform  a limited  evaluation  of  the  AP  information  model 
set,  the  AP  format  specification,  and  the  set  of  test  cases.  This  review  and  evaluation 
will  be  done  for  the  purpose  of  assisting  the  IGES/PDES  technical  committees  in 
preparing  and  refining  APs. 

A summary  list  of  the  individual  components  necessary  for  AP  validation  is  given  below. 

a.  APs  application-based  NIAM,  IDEF1X,  or  Express  information  model. 

b.  Detailed  glossary  and  supporting  documentation  for  the  information  model. 

c.  Detailed  specification  of  the  constraints  and  business  rules  for  the  informa- 
tion model 

d.  AP  format’s  list  of  IGES  entities  and  AP  information  mapping  table. 
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e.  AP  format’s  detailed  restrictions  for  the  global,  directory  entry,  and 
parameter  data  sections  for  the  IGES  entities. 

f.  AP  format’s  detailed  usage  guide  for  the  IGES  entities. 

g.  AP  format’s  test  cases  and  accompanying  documentation. 


3.3.1  Application  Protocol  Validation  Procedures 


A summary  of  the  validation  procedures  for  a candidate  AP  is  given  below  in  one  sen- 
tence statements,  followed  by  a more  detailed  description  of  the  complete  methodol- 
ogy: 

1.  Content  validation  is  done  for  the  purpose  of  evaluating  the  completeness  and  cor- 
rectness of  the  conceptual  information  model’s  representation  of  the  information  re- 
quirements for  the  application  area. 

2.  Information  representation  validation  is  done  for  the  purpose  of  evaluating  the  ap- 
plication protocol  format’s  representation  of  the  information  requirements  as  specified 
by  the  conceptual  information  model 


3.  Application 


verification  is  done  for  the  purpose  of 
evaluating  the  completeness  and  syntactical  correctness  of  the  implementation  of  the 
AP  format  in  the  test  cases. 


Part  1,  the  content  evaluation  part  of  this  validation,  will  be  manpower  intensive.  Due 
to  the  current  state  of  information  modeling  software  tools,  it  is  not  possible  to  simply 
use  a computer  program  to  evaluate  the  information  model  for  completeness  or  cor- 
rectness. This  validation  will  involve  a team  of  experts  from  the  subject  application 
area. 


The  authoring  committee  and  the  AVM  Committee  must  jointly  designate  the  mem- 
bers of  this  content  validation  team.  For  an  optimum  validation  of  the  information 
model,  these  application  experts  should  not  be  the  same  experts  that  participated  in 
the  development  of  the  information  model.  When  it  is  not  possible  to  obtain  applica- 
tion experts  that  did  not  participate  in  the  information  model  development,  this  re- 
quirement may  be  waived  if  both  the  authoring  committee  and  the  AVM  Committee 
are  satisfied  with  the  submitted  content  validation  documentation. 


In  either  case,  a group  of  experts  from  the  application  area  must  be  called  upon  to  per- 
form the  task  of  evaluating  the  content  of  the  conceptual  information  model  and  its  ac- 
companying documentation.  Most,  if  not  all  of  this  evaluation  will  have  to  be  done 
manually.  It  is  however  possible  to  provide  the  group  of  application  area  experts  some 
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computer  tools  to  aid  in  the  task  of  preparing  different  forms  of  the  information  model 
for  analysis.  For  example,  a NIAM  model  is  based  on  the  structure  of  English  language 
sentences  that  contain  a subject  and  a predicate  and  give  information  about  the  struc- 
ture and  meaning  of  the  information  that  is  required  in  the  application  area.  For  a 
NIAM  model,  it  may  be  helpful  to  use  a computer  tool  to  process  the  entire  model  into 
the  form  of  grouped  and  structured  English  language  sentences  that  contain  the  struc- 
ture and  meaning  of  the  information. 

This  part  of  the  validation  most  likely  will  have  to  be  done  on  a paper  form  of  the  model. 
The  conceptual  information  model  must  be  evaluated  on  the  basis  of  information  re- 
quirements, before  the  AP  format  is  evaluated.  It  makes  no  sense  to  attempt  an  evalua- 
tion of  the  AP  format  without  validating  the  candidate  conceptual  information  model 
first.  The  success  criteria  for  this  validation  is  that  the  information  model  accurately 
specifies  all  of  the  information  requirements  for  the  application  area. 

The  evaluation  must  be  done  in  an  incremental  way  such  that  each  expert  will  study 
and  evaluate  a section  of  the  information  model  and  produce  an  evaluation  report  on 
that  section  of  the  model.  These  experts  must  use  all  of  the  information  from  items  a. 
through  c.  in  Section  3.3.  The  evaluation  report  must  identify  that  expert’s  assessment 
of  any  deficiencies  in  the  information  model. 

If  this  step  in  the  validation  is  not  passed  successfully,  the  evaluation  report  must  in- 
clude a high  level  summary  of  the  areas  where  emphasis  is  required  in  the  next  itera- 
tion of  the  AP’s  conceptual  model  development.  In  this  case,  the  validation  will  not 
continue  into  Part  2. 

When  this  step  in  the  validation  process  is  passed,  a summary  report  must  be  produced 
to  describe  the  successful  information  model  validation.  This  must  include  the  in- 
cremental validation  reports  for  the  sections  of  the  conceptual  model,  as  completed  by 
the  application  area  experts. 

Part  2,  the  information  representation  validation  of  the  AP,  involves  the  evaluation  of 
the  AP  format’s  ability  to  carry  all  of  the  information  requirements  specified  by  the 
validated  conceptual  information  model.  This  validation  must  check  that  all  items  of 
information  specified  by  the  information  model  can  be  carried  in  the  AP  format  as 
specified  by  the  usage  guide.  This  part  of  the  validation  will  require  both  application 
area  experts  and  experts  in  the  capabilities  and  use  of  IGES. 

This  validation  procedure  will  include  traversing  the  information  model  and  identify- 
ing each  element  of  required  information.  The  AP  format  specification  is  required  to 
contain  a usage  guide  for  the  IGES  entities.  The  usage  guide  must  be  used  to  find  the 
location  in  the  AP  format’s  IGES  entity  set  where  each  element  of  information  is  to  be 
carried.  The  IGES  entity  must  then  be  evaluated  on  its  ability  to  carry  the  required  in- 
formation, embedded  as  specified  by  the  usage  guide. 
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This  procedure  must  be  completed  for  the  entire  conceptual  information  model.  The 
experts  that  perform  this  validation  step  must  use  all  of  the  information  from  items  d. 
through  f.  in  Section  3.3.  As  an  aid  in  completing  this  procedure,  the  AP  information 
mapping  table  (described  in  Section  3.2.2)  shall  be  used  to  check  the  IGES  entity  type 
or  types  that  are  specified  to  carry  each  element  or  group  of  information  from  the  in- 
formation model. 

This  validation  step  will  be  passed  when  all  information  requirements  specified  by  the 
conceptual  information  model  are  verified  to  be  accurately  carried  by  the  AP  format. 
If  any  single  information  requirement  from  the  conceptual  information  model  cannot 
be  supported  by  the  AP  format,  this  validation  step  will  be  failed. 

When  this  step  in  the  validation  is  passed,  a summary  report  must  be  produced,  con- 
sisting of  the  verified  AP  information  mapping  table  and  a description  of  the  success- 
ful AP  format  validation.  If  this  step  in  the  validation  is  not  passed,  the  report  must 
give  a high  level  summary  of  the  areas  where  emphasis  is  required  in  the  next  iteration 
of  the  AP  format’s  development.  In  this  case,  the  validation  must  not  continue  into 
Part  3. 

Part  3,  the  AP  format  compliance  verification,  evaluates  the  completeness  and  syntac- 
tical correctness  of  the  implementation  of  the  AP  format  in  a set  of  AP  format  test 
cases.  Test  cases  must  be  provided  for  testing  both  pre-  and  postprocessors. 

This  part  of  the  AP  validation  must  use  all  of  the  information  in  items  d.,  e.,  and  f.  in 
Section  3.3.  The  protocol  usage  guide  must  be  used  to  verify  that  the  semantics  (the 
meaning)  from  the  conceptual  information  model  have  been  accurately  represented  in 
the  set  of  test  cases.  The  supporting  documentation  for  the  test  cases  will  be  absolute- 
ly necessary  in  this  part  of  the  validation.  This  step  must  also  include  checking  the  syn- 
tactic correctness  of  the  AP  format  test  cases. 

One  tool  to  assist  in  this  verification  procedure  would  be  an  IGES  file  syntax  checker. 
A standard  IGES  file  syntax  checker  could  be  modified  to  use  the  syntax  and  entity 
types  of  an  AP  format.  Since  no  AP  syntax  checkers  currently  exist,  and  until  IGES  file 
syntax  checkers  are  robust  enough  to  check  for  AP  formats,  much  of  this  verification 
will  have  to  be  done  manually. 

It  is  imperative  that  the  protocol  usage  guide  be  followed  to  correctly  embed  the  infor- 
mation in  the  required  list  of  IGES  entities.  Therefore,  if  the  set  of  AP  format  test 
cases  can  be  verified  to:  (i)  contain  syntactically  and  semantically  correct  information 
per  the  conceptual  information  model  and  the  protocol  usage  guide,  and  (ii)  contain 
an  implementation  of  all  information  requirements  of  the  AP  s conceptual  informa- 
tion model,  this  evaluation  will  be  passed.  If  any  syntactic  or  semantic  deficiency  is 
found,  or  any  information  requirement  is  not  implemented,  this  part  of  the  process  will 
be  failed. 
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This  set  of  AP  format  test  cases  may  be  used  as  part  of  the  necessary  set  of  test  cases 
for  a future  AP  conformance  program  for  vendors,  developers,  users,  etc.  These  test 
cases  will  undoubtedly  not  be  all  of  the  test  cases  that  would  be  needed  for  such  a 
program. 

When  this  step  in  the  validation  is  passed,  the  results  must  consist  of  a verified  set  of 
AP  test  cases  and  a summary  report  documenting  the  successful  verification  of  the  AP 
format  test  set.  If  this  step  is  not  passed,  the  report  must  give  a high  level  summary  of 
the  areas  where  emphasis  is  required  in  the  next  iteration  of  the  AP  format  test  case 
development. 


3.4  Application  Protocol  Approval  Procedures 


The  AVM  Committee  will  accept  candidate  AP  packages  from  the  IGES/PDES  tech- 
nical committees  that  prepare  them.  Upon  receiving  an  AP  package,  the  AVM  Com- 
mittee will  inventory  the  AP  package  for  the  required  technical  content  before  any 
technical  evaluation  is  performed. 

If  any  of  the  required  items  are  absent  from  the  AP  package  or  are  evaluated  as  insuf- 
ficient per  Section  3.3.1,  the  AVM  Committee  will  prepare  a summary  list  including  an 
explanation  of  the  missing  items.  The  AP  package,  with  this  summary  report,  will  be 
returned  to  the  appropriate  IGES/PDES  technical  committee.  The  AVM  Committee 
will  work  with  those  committees  that  are  submitting  candidate  APs  to  resolve  any  iden- 
tified deficiencies. 

Application  protocols  will  go  through  distinct  stages  of  development,  testing,  and  ap- 
proval. These  stages  are  classified  as  Preliminary,  Trial,  Draft,  and  Recommended, 
with  following  meanings. 


- Preliminary  AP:  Under  development,  not  completely  validated  by  the 

authors 

- Trial  AP:  Submitted  by  the  authors  for  full  testing  and  validation  by  inter- 
ested organizations 

- Draft  AP:  Approved  by  the  lead  IGES/PDES  technical  committee 

- Recommended  AP:  Approved  by  the  IGES/PDES  AVM  and  Edit  Commit- 
tees 
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Before  an  AP  can  be  approved  by  the  IGES/PDES  Edit  Committee,  the  protocol  must 
be  implemented  on  at  least  two  dissimilar  systems,  and  those  two  systems  must  ex- 
change files  in  both  directions  according  to  the  protocol.  This  exchange  may  require 
reprocessing  the  IGES  files  with  software  tools  in  addition  to  system  provided  IGES 
translators,  or  it  may  require  custom  modification  of  the  system  provided  IGES  trans- 
lators. 

Once  a candidate  AP  has  been  specified  and  validated  per  these  guidelines,  it  can  be 
approved  by  the  AVM  Committee.  With  this  approval,  the  candidate  AP  can  be 
presented  to  the  Edit  Committee  of  the  IGES/PDES  Organization  for  approval  as  a 
Recommended  IGES  Application  Protocol. 
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4.  Guidelines  for  the  Implementation  of  an 
Approved  IGES  Application  Protocol 


The  exchange  of  product  definition  information  between  dissimilar  CAD  systems  is 
greatly  affected  by  the  sequence  of  the  format  translations  in  the  exchange.  In  order 
to  successfully  implement  an  application  protocol  process,  it  is  necessary  to  implement 
a reliable  approach  for  Information  Configuration  Control  and  Software  Configura- 
tion Control.  For  some  product  definition  exchange  environments,  component  parts 
of  such  an  approach  are  in  place  or  under  development.  However,  for  an  application 
protocol  process  to  be  successful,  the  participating  organizations  must  establish  Infor- 
mation Configuration  Control  and  Software  Configuration  Control  for  their  product 
definition  creation  and  exchange  systems. 

To  understand  why  Information  Configuration  Control  and  Software  Configuration 
Control  are  needed  in  an  application  protocol  process,  it  is  necessary  to  examine  the 
sequence  of  steps  and  software  units  through  which  CAD  information  must  pass  in  the 
translation  from  the  database  format  of  one  CAD  system  through  an  IGES  application 
protocol  format  to  the  database  format  of  another  CAD  system.  In  an  application 
protocol  process,  documentation  is  required  to  define  each  format  and  the  information 
mappings  between  the  formats.  The  Application  Protocol  Information  Model  and  the 
Application  Protocol  Format  Specification  must  be  used  to  prepare  this  documenta- 
tion. 

For  an  application  protocol  process,  there  are  two  essential  points  to  be  made: 

1.  The  syntax  (the  format)  and  semantics  (the  meaning)  at  each  format  step  must 
be  specified  by  documentation  which  is  under  configuration  control.  This  ap- 
proach will  be  called  Information  Configuration  Control  (ICC). 

2.  The  Application  Protocol  Format  Specification  specifies  the  IGES  entities 
and  the  restrictions  on  the  entities  that  will  be  used  to  carry  each  element  of  in- 
formation from  the  application  protocol  information  model.  The  ICC 
documentation  provides  a basis  for  documentation  of  the  information  mappings 
between  the  formats.  Therefore,  the  software  that  translates  the  information 
between  the  formats  must  be  written  on  the  basis  of  the  ICC  syntax  and  seman- 
tics specified  in  that  documentation.  This  is  a first  step  in  Software  Configura- 
tion Control  (SCO. 


There  are  two  ways  to  implement  an  application  protocol  process  for  translating  CAD 
information  from  the  database  format  of  a System  A into  an  IGES  AP  format,  and  then 
translating  that  information  from  the  IGES  AP  format  into  the  database  format  of  a 
System  B.  Each  of  the  two  ways  is  based  on  a specific  AP  process  "structure"  that  con- 
sists of  certain  formats  and  software  units. 
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Figure  2 illustrates  the  first  AP  process  structure.  Figure  2 shows  five  rectangles  that 
represent  the  formats  used  in  translating  information  from  the  database  format  of  Sys- 
tem A into  the  IGES  AP  format,  and  then  into  the  database  format  of  System  B.  ICC 
must  be  imposed  by  specifying  the  syntax  and  semantics  to  be  used  in  the  creation  and 
translation  of  CAD  information  between  these  formats.  For  use  in  SCC,  the  ICC  syn- 
tax and  semantics  documentation  must  have  a version  number  and  a date  of  release. 

The  first  rectangle  in  Figure  2 represents  CAD  information  created  in  System  A.  The 
purpose  of  this  format  step  is  to  create  the  information  using  a well-defined  set  of 
capabilities  available  on  System  A such  that  the  constructs  in  the  CAD  database  con- 
form to  the  ICC  specifications.  The  ICC  syntax  and  semantics  for  this  format  step  could 
be  contained  in  the  document  called  "CAD  Standards  and  Practices  for  System  A". 
These  user  modeling  standards  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  CAD  information  for  the  application  protocol  using  the  user  inter- 
face available  on  System  A. 

semantics  - what  each  item  of  CAD  information  that  is  to  be  created  and 
manipulated  means  for  the  application  protocol. 


The  second  rectangle  in  Figure  2 represents  the  CAD  information  in  the  IGES  repre- 
sentation format  of  System  A.  The  purpose  of  this  format  step  is  to  represent  the  CAD 
information  from  System  A in  a nonproprietary  format  for  subsequent  manipulation 
as  required.  The  IGES  representation  format  does  not  have  well-defined  semantics 
for  the  CAD  information  produced  by  System  A.  Therefore,  the  semantics  for  this  for- 
mat step  must  be  derived  from  analysis  of  the  CAD  information  produced  by  System 
A after  translation  into  the  IGES  representation  format.  The  ICC  syntax  for  this  for- 
mat step  is  contained  in  a document  called  "The  Initial  Graphics  Exchange  Specifica- 
tion." The  ICC  syntax  and  semantics  for  this  format  step  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  representing  each  item  of 
CAD  information  in  the  IGES  representation  format  for  System  A.  This  syn- 
tax is  a function  of  the  application  protocol,  the  structure  of  System  A,  the  user 
interface  of  System  A,  and  the  software  unit  for  System  A that  translates  the 
CAD  information  into  the  IGES  representation  format. 

semantics  - result  of  how  each  item  of  CAD  information  is  dispersed  when  it  is 
translated  into  the  IGES  representation  format  for  System  A due  to  the  vari- 
ables associated  with  the  ICC  syntax. 


The  third  rectangle  in  Figure  2 represents  the  CAD  information  from  System  A in  the 
IGES  AP  format.  The  purpose  of  this  format  step  is  to  prepare  the  CAD  information 
in  an  application  specific  format  that  is  independent  of  any  individual  CAD  system. 
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BASED  ON  "GENERIC"  IGES  TRANSLATORS 


The  ICC  syntax  for  this  format  step  must  be  contained  in  the  A P format  specification. 
The  semantics  for  this  format  step  must  be  contained  in  the  AP  information  model. 
The  ICC  documentation  for  this  format  step  is  required  as  part  of  an  approved  AP.  For 
an  approved  Mechanical  Drafting  AP,  this  documentation  could  be  called  the 
"Mechanical  Drafting  Information  Model"  and  the  "Mechanical  Drafting  Application 
Protocol  Format  Specification."  The  ICC  syntax  and  semantics  for  this  format  step 
must  define: 

syntax  - the  choice  of  the  format  and  structure  of  how  each  item  of  CAD  infor- 
mation from  the  AP  information  model  is  to  be  carried  in  the  AP  format. 

semantics  - what  each  item  of  CAD  information  in  the  AP  format  means  accord- 
ing to  the  AP  information  model. 


The  fourth  rectangle  in  Figure  2 represents  the  CAD  information  in  the  IGES  repre- 
sentation format  as  required  by  System  B.  The  purpose  of  this  format  step  is  to  provide 
the  CAD  information  from  the  application  specific  IGES  format  into  the  form  required 
by  System  B.  Again,  the  IGES  representation  format  does  not  have  well-defined 
semantics  for  the  CAD  information.  Therefore,  the  semantics  for  this  format  step  must 
be  determined  on  the  basis  of  how  the  CAD  information  must  be  embedded  into  the 
IGES  entities  as  required  by  System  B.  The  ICC  syntax  for  this  format  step  is  contained 
in  a document  called  "The  Initial  Graphics  Exchange  Specification."  The  ICC  syntax 
and  semantics  for  this  format  step  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  representing  each  item  of 
CAD  information  for  the  AP  in  the  IGES  representation  format  for  System  B. 
This  syntax  is  a function  of  the  AP,  the  structure  of  System  B,  the  user  interface 
of  System  B,  and  the  software  unit  for  System  B that  translates  the  CAD  infor- 
mation from  the  IGES  representation  format. 

semantics  - result  of  how  each  item  of  CAD  information  must  be  dispersed  when 
it  is  translated  from  the  IGES  representation  format  for  System  B due  to  the 
variables  associated  with  the  ICC  syntax. 


The  fifth  rectangle  in  Figure  2 represents  the  translated  CAD  information  in  the  for- 
mat of  System  B.  The  purpose  of  this  format  step  is  to  provide  the  CAD  information 
in  System  B format  such  that  the  original  CAD  information  can  be  manipulated  in  the 
same  way  as  if  it  were  created  on  System  B.  The  ICC  syntax  and  semantics  for  this  for- 
mat step  could  be  contained  in  a document  called  "CAD  Standards  and  Practices  for 
System  B"  and  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  CAD  information  for  the  AP  using  the  user  interface  available  on 
System  B. 

semantics  - what  each  item  of  CAD  information  that  is  to  be  created  and 
manipulated  means  for  the  AP. 
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The  four  circles  in  Figure  2 represent  the  software  units  that  translate  the  CAD  infor- 
mation from  the  System  A database  format  through  the  IGES  AP  format  to  the  Sys- 
tem B database  format.  SCC  must  be  imposed  by  requiring  that  two  of  these  software 
units,  the  IGES  AP  format  preprocessor  and  the  IGES  AP  format  postprocessor,  be 
written  on  the  basis  of  the  ICC  syntax  and  semantics  defined  in  the  documentation 
above. 

The  first  circle  in  Figure  2 represents  the  "generic"  IGES  preprocessor  for  System  A 
that  translates  CAD  information  from  the  CAD  database  format  for  System  A to  the 
IGES  representation  format.  A generic  IGES  translator  is  an  application  independent 
IGES  translator.  In  general,  a generic  IGES  preprocessor  and  a generic  IGES 
postprocessor  for  a certain  CAD  system  can  be  used  to  implement  different  applica- 
tion protocols. 

The  generic  translator  implements  a single  mapping  association  between  an  entity  in 
the  CAD  database  format  and  an  entity(s)  in  the  IGES  format,  or  vice  versa.  The  single 
mapping  association  is  based  only  on  the  similarity  of  the  CAD  database  structure  and 
the  IGES  data  structures.  Because  the  IGES  format  does  not  have  well-defined 
semantics,  the  mapping  results  in  a dispersion  of  the  information  in  the  IGES  repre- 
sentation. 

The  second  circle  in  Figure  2 represents  the  IGES  AP  format  preprocessor  that  trans- 
lates CAD  information  from  the  IGES  representation  format  for  System  A to  the  IGES 
AP  format.  This  software  unit  must  be  written  on  the  basis  of  the  ICC  syntax  and  seman- 
tics contained  in  the  "CAD  Standards  and  Practices  for  System  A"  the  ICC  syntax  con- 
tained in  the  IGES  specification  and  the  ICC  syntax  and  semantics  contained  in  the  AP 
format  specification  and  the  AP  information  model.  The  ICC  syntax  and  semantics 
specified  by  these  documents  plus  the  mappings  documented  for  the  generic  IGES 
preprocessor  provides  the  basis  for  a document  called  "The  Mapping  of  CAD  Informa- 
tion from  the  IGES  Format  to  the  Application  Protocol  Format  for  System  A."  The 
IGES  AP  format  preprocessor  must  implement  these  mappings  to  prepare  the  CAD 
information  in  the  AP  format. 

The  third  circle  in  Figure  2 represents  the  IGES  AP  format  postprocessor  that  trans- 
lates CAD  information  from  the  IGES  AP  format  to  the  IGES  representation  format 
for  System  B.  This  software  unit  must  be  written  on  the  basis  of  the  ICC  syntax  and 
semantics  contained  in  the  CAD  Standards  and  Practices  for  System  B,  the  ICC  syntax 
contained  in  the  "Initial  Graphics  Exchange  Specification",  and  the  ICC  syntax  and 
semantics  contained  in  the  AP  format  specification  and  the  AP  information  model. 
The  ICC  syntax  and  semantics  specified  by  these  documents  plus  the  mappings  for  the 
generic  IGES  postprocessor  for  System  B provides  the  basis  for  a document  called  "The 
Mapping  of  CAD  Information  from  the  Application  Protocol  Format  to  the  IGES  For- 
mat for  System  B."  The  IGES  AP  format  postprocessor  must  implement  these  map- 
pings to  read  the  CAD  information  from  the  AP  format. 
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The  fourth  circle  in  Figure  2 represents  the  generic  IGES  postprocessor  for  System  B 
that  translates  CAD  information  from  the  IGES  representation  format  to  the  CAD 
database  format  for  System  B.  The  generic  IGES  postprocessor  is  supplied  by  the  ven- 
dor of  System  B and  is  based  only  on  the  capabilities  of  the  CAD  system  and  the  sys- 
tem structure.  The  result  of  this  is  that  the  syntax  for  the  "mapping"  of  information  from 
the  IGES  representation  format  to  the  CAD  database  format  for  System  B is  based  on 
only  the  syntax  of  the  CAD  database  format  for  System  B and  the  IGES  representation 
format. 

Figure  3 illustrates  the  second  application  protocol  process  structure.  This  AP  process 
structure  is  a "direct"  process  for  translating  CAD  information  from  the  CAD  database 
format  of  System  A into  an  IGES  AP  format,  and  then  from  the  IGES  AP  format  into 
the  CAD  database  format  of  System  B.  Figure  3 illustrates  the  long-term  objective  of 
AP  methodology. 

Figure  3 shows  three  rectangles  that  represent  the  formats  used  in  transforming  CAD 
information  directly  from  the  System  A database  format  through  the  IGES  AP  format 
to  the  System  B database  format.  ICC  must  be  imposed  here  by  specifying  the  syntax 
and  semantics  to  be  used  in  the  creation  and  translation  of  CAD  information  between 
these  formats.  Again,  for  use  in  SCC,  the  ICC  syntax  and  semantics  documentation 
must  have  a version  number  and  a date  of  release. 

The  first  rectangle  in  Figure  3 represents  the  creation  of  CAD  information  in  System 
A.  As  shown  in  Figure  3,  the  ICC  syntax  and  semantics  for  this  format  step  are  based 
explicitly  on  the  AP  information  model.  Therefore,  the  creation  of  the  CAD  informa- 
tion in  System  A is  based  on  embedding  each 

item  of  information  from  the  AP  information  model  into  the  CAD  database  format  of 
System  A.  The  ICC  syntax  and  semantics  for  this  format  step  could  be  contained  in  a 
document  called  "CAD  Standards  and  Practices  for  an  Application  Protocol  for  Sys- 
tem A"  and  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  CAD  information  for  the  AP  using  the  user  interface  available  on 
System  A. 

semantics  - what  each  item  of  CAD  information  in  the  CAD  database  format  of 
System  A means  according  to  the  AP  information  model. 


The  second  rectangle  in  Figure  3 represents  the  CAD  information  from  System  A in 
the  IGES  AP  format.  The  purpose  of  this  format  step  is  to  prepare  the  CAD  informa- 
tion in  an  application  specific  format  that  is  independent  of  any  individual  CAD  sys- 
tem. The  ICC  syntax  for  this  format  step  must  be  contained  in  the  AP  format  specifica- 
tion. 
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BASED  ON  APPLICATION  PROTOCOL  FORMAT  TRANSLATORS 


The  ICC  semantics  for  this  format  step  must  be  contained  in  the  AP  information  model. 
The  ICC  syntax  and  semantics  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  representing  each  item  of 
CAD  information  for  the  AP  in  the  AP  format. 

semantics  - what  each  item  of  CAD  information  in  the  AP  format  means  accord- 
ing to  the  AP  information  model. 


The  third  rectangle  in  Figure  3 represents  the  translated  CAD  information  in  System 
B.  As  shown  in  Figure  3,  the  ICC  syntax  and  semantics  for  this  format  step  are  based 
explicitly  on  the  AP  information  model.  Therefore,  the  translation  of  the  CAD  infor- 
mation into  System  B is  based  on  embedding  each  item  of  information  from  the  AP  in- 
formation model  into  the  CAD  database  format  of  System  B.  The  ICC  syntax  and 
semantics  for  this  format  step  could  be  contained  in  a document  called  "CAD  Stand- 
ards and  Practices  for  an  Application  Protocol  for  System  B"  and  must  define: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  CAD  information  for  the  AP  using  the  user  interface  available  on 
System  B. 

semantics  - what  each  item  of  CAD  information  in  the  CAD  database  format  of 
System  B means  according  to  the  AP  information  model. 


The  two  circles  in  Figure  3 represent  the  software  units  that  translate  CAD  informa- 
tion directly  from  the  CAD  database  format  for  System  A through  the  IGES  AP  for- 
mat to  the  CAD  database  format  of  System  B.  The  first  circle  in  Figure  3 represents 
the  IGES  AP  format  preprocessor  for  System  A that  translates  CAD  information  from 
the  System  A format  directly  to  the  IGES  AP  format.  This  software  unit  must  be  writ- 
ten on  the  basis  of  the  ICC  syntax  and  semantics  contained  in  the  CAD  Standards  and 
Practices  for  the  AP  for  System  A and  the  ICC  syntax  and  semantics  contained  in  the 
AP  format  specification  and  the  AP  information  model.  The  ICC  syntax  and  seman- 
tics specified  by  these  documents  provides  the  basis  for  a document  called  "The  Map- 
ping of  CAD  Information  to  an  Application  Protocol  Format  for  System  A." 

The  second  circle  in  Figure  3 represents  the  IGES  AP  format  postprocessor  for  Sys- 
tem B that  translates  CAD  information  from  the  IGES  AP  format  directly  to  the 
database  format  for  System  B.  This  software  unit  must  be  written  on  the  basis  of  the 
ICC  syntax  and  semantics  contained  in  the  CAD  Standards  and  Practices  for  an  AP  for 
System  B,  and  the  ICC  syntax  and  semantics  contained  in  the  AP  format  specification 
and  the  AP  information  model.  The  ICC  syntax  and  semantics  specified  by  these  docu- 
ments provides  the  basis  for  a document  called  "The  Mapping  of  CAD  Information 
from  an  Application  Protocol  Format  for  System  B." 

Figure  2 and  Figure  3 describe  AP  processes  that  are  based  on  the  use  of  "generic"  IGES 
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translators  and  special  AP  format  translators,  respectively.  Neither  Figure  2 or  Figure 
3 is  intended  to  imply  that  a computer-understandable  reversible  mapping  exists  be- 
tween the  information  in  the  AP  information  model  and  the  information  contained  in 
the  AP  format  IGES  file. 

A crucial  point  of  both  figures  is  that  there  must  exist  a human-understandable  revers- 
ible mapping  between  the  information  requirements  in  the  AP  information  model  and 
the  system  entities  needed  to  carry  the  information  in  System  A.  When  obtained,  this 
mapping  can  be  used  by  a human  to  develop  usage  conventions  for  creating  AP  infor- 
mation in  System  A.  There  must  also  exist  a second  human-understandable  reversible 
mapping  between  the  system  entities  in  System  A and  the  IGES  entities  in  the  AP  for- 
mat. In  addition,  since  both  mappings  are  reversible,  the  mappings  can  be  used  by  a 
human  to  prepare  computer  software  to  automatically  perform  the  reverse  mapping 
between  the  IGES  entities  in  the  AP  format  and  System  A entities  or  system  entities 
in  a dissimilar  System  B. 

The  existence  of  both  mappings  is  critical  to  accomplishing  the  successful  exchange  of 
the  information  in  the  AP  information  model  between  System  A and  System  B.  With 
the  first  mapping  established,  the  second  mapping,  between  the  System  A entities  and 
the  IGES  entities  in  the  AP  format,  can  be  developed.  With  human-developed  usage 
conventions  for  System  A,  a human  can  prepare  computer  software  to  automatically 
perform  the  mapping. 


4.1  Example  of  an  Application  Protocol  Process 


Currently,  it  is  not  possible  to  implement  an  application  protocol  process  based  on  the 
structure  of  Figure  3.  This  is  because  no  approved  IGES  APs  exist,  and  because  no 
APs  have  been  implemented  by  vendors  of  CAD  systems.  Therefore,  AP  processes 
must  currently  be  developed  and  implemented  by  users,  and  these  processes  must  be 
based  on  the  structure  of  Figure  2. 

Consider  an  example  of  a user  developed  AP  process,  shown  in  Figure  4,  and  based  on 
the  structure  shown  in  Figure  2.  The  AP  described  in  this  example  is  partially  com- 
plete, as  per  the  technical  content  requirements  of  Section  3.1.  This  example  does  not 
have  a complete  AP  information  model  with  all  of  the  required  supporting  documen- 
tation. It  does  include  an  AP  format  specification,  which  consists  of  the  IGES  entity 
set,  the  restrictions  on  the  global,  directory  entry,  and  parameter  data  section  field 
values,  and  a partial  usage  guide  for  the  IGES  entities. 
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APPLICATION  PROTOCOL  PROCESS 
DEVELOPED  BY  DOE/NWC 


The  example  is  of  an  AP  format  called  the  "Department  of  Energy  Data  Exchange  For- 
mat, Mechanical  Products/Drafting."1  Specifically,  this  is  an  example  of  a partially  com- 
plete AP  for  mechanical  part/product  drawings.  In  terms  of  Figure  2,  the  AP  format 
will  be  called  the  Department  of  Energy  Data  Exchange  Format,  Mechanical 
Products/Drafting. 

This  example  is  based  on  one  of  the  CAD  systems  currently  in  use  at  Sandia  National 
Laboratories,  Albuquerque,  New  Mexico,  the  Applicon  AGS/880  IMAGE  CAD  sys- 
tem. For  simplicity,  this  example  will  discuss  the  AP  process  with  the  notion  of  "loop- 
ing" the  CAD  information  out  of  and  back  into  the  AGS/880  system.  Therefore,  in 
terms  of  Figure  2,  System  A and  System  B will  both  be  the  AGS/880  system. 

The  first  rectangle  in  Figure  4 represents  the  creation  of  mechanical  part/product  draw- 
ing information  in  the  AGS/880  system.  The  purpose  of  this  format  step  is  to  create 
the  information  using  a well-defined  set  of  capabilities  available  on  the  AGS/880  sys- 
tem. The  creation  is  done  such  that  the  constructs  in  the  AGS/880  database  conform 
to  the  ICC  specifications.  The  ICC  syntax  and  semantics  for  this  format  step  are  con- 
tained in  a document  called  "General  CAD  Practices  and  File  Standards"  [4],  for  the 
AGS/880  system.  This  documentation  defines: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  mechanical  part/product  drawing  information  using  the  user  inter- 
face available  on  the  AGS/880  system. 

semantics  - what  each  item  of  mechanical  part/product  drawing  information  that 
is  to  be  created  and  manipulated  means  for  the  mechanical  part/product  draw- 
ing application. 


The  second  rectangle  in  Figure  4 represents  the  mechanical  part/product  drawing  in- 
formation in  the  IGES  format  for  the  AGS/880  system.  The  purpose  of  this  format  step 
is  to  represent  the  information  in  a nonproprietary  format  for  subsequent  manipula- 
tion as  required.  The  IGES  format  does  not  have  well-defined  semantics  for  the  infor- 
mation. 

The  syntax  for  this  format  step  was  derived  from  analysis  of  the  information  as  it  was 


1 Certain  commercial  equipment,  software,  or  materials  are  identified  in  this 
document  in  order  to  adequately  specify  existing  CAD  software  and  data 
exchange  mechanisms.  Such  identification  does  not  imply  endorsement  by  the 
National  Institute  of  Standards  and  Technology  or  the  IGES/PDES 
Organization,  nor  does  it  imply  that  the  software  or  equipment  are  necessarily 
the  best  available  for  the  purpose. 
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represented  in  the  IGES  format.  The  ICC  syntax  for  this  format  step  is  based  on  a docu- 
ment called  "The  Initial  Graphics  Exchange  Specification."^]  The  ICC  syntax  and 
semantics  for  this  format  step  are  contained  in  a document  called  "Requirements  for 
the  Applicon  AGS/880  IMAGE  CAD  System  Deflavor  Translator."[6]  The  ICC  syn- 
tax and  semantics  for  this  format  step  define: 

syntax  - the  choice  of  the  format  and  structure  for  representing  each  item  of 
mechanical  part/product  drawing  information  for  the  AGS/880  system  in  the 
IGES  format.  This  syntax  is  a function  of  the  variables:  the  mechanical 
part/product  drawing  application,  the  structure  of  the  AGS/880  system,  and  the 
AGS/880  IGES  preprocessor. 

semantics  - what  each  item  of  mechanical  part/product  drawing  information  that 
is  to  be  created  and  manipulated  means  for  the  mechanical  part/product  draw- 
ing application.  The  semantics  cannot  be  determined  by  the  types  of  the  result- 
ing IGES  entities.  This  is  because  each  item  of  information  is  dispersed  when 
it  is  translated  by  the  AGS/880  IGES  preprocessor,  due  to  the  variables  as- 
sociated with  the  ICC  syntax. 

The  third  rectangle  in  Figure  4 represents  the  mechanical  part/product  drawing  infor- 
mation in  the  Department  of  Energy  Data  Exchange  Format,  Mechanical 
Products/Drafting.  The  purpose  of  this  format  step  is  to  prepare  the  information  in  an 
application  specific  format  that  is  independent  of  any  individual  CAD  system.  The  ICC 
syntax  for  this  format  step  is  contained  in  the  Department  of  Energy  Data  Exchange 
Format.  The  partial  semantics,  i.e.,  the  partial  mechanical  part/product  drawing  infor- 
mation model,  for  this  format  step  are  also  contained  in  the  Department  of  Energy 
Data  Exchange  Format.  The  ICC  syntax  and  semantics  for  this  format  step  currently 
define: 

syntax  - the  choice  of  the  format  and  structure  for  encoding  each  item  of  infor- 
mation from  the  mechanical  part/product  drawing  information  model  in  the 
Department  of  Energy  Data  Exchange  Format. 

semantics  - what  items  of  information  in  the  Department  of  Energy  Data  Ex- 
change Format  mean  according  to  the  partial  mechanical  part/product  drawing 
information  model. 


The  fourth  rectangle  in  Figure  4 represents  the  mechanical  part/product  drawing  in- 
formation in  the  IGES  format.  The  purpose  of  this  format  step  is  to  provide  the  infor- 
mation in  the  IGES  format  as  required  by  the  AGS/880  system.  Again,  the  IGES  for- 
mat does  not  have  well-defined  semantics  for  the  information.  The  syntax  for  the  in- 
formation in  this  format  step  was  determined  by  how  the  AGS/880  IGES  postproces- 
sor expects  the  information  to  be  embedded  in  IGES  entities.  For  the  AGS/880  sys- 
tem, the  required  syntax  for  this  format  step  is  the  same  as  that  of  the  second  rectangle 
in  Figure  4.  The  ICC  syntax  for  this  format  step  is  based  on  a document  called  The  In- 
itial Graphics  Exchange  Specification.  The  ICC  syntax  and  semantics  for  this  format 
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step  are  contained  in  a document  called  "Requirements  for  the  Applicon  AGS/880 
IMAGE  CAD  System  Reflavor  Translator."[7]  The  ICC  syntax  and  semantics  for  this 
format  step  define: 

syntax  - the  choice  of  the  format  and  structure  for  representing  each  item  of 
mechanical  part/product  drawing  information  for  the  AGS/880  system  in  the 
IGES  format.  This  syntax  is  a function  of  the  variables:  the  mechanical 
part/product  drawing  application,  the  structure  of  the  AGS/880  system,  and  the 
AGS/880  IGES  preprocessor. 

semantics  - what  each  item  of  mechanical  part/product  drawing  information  that 
is  to  be  created  and  manipulated  means  for  the  mechanical  part/product  draw- 
ing application.  The  semantics  cannot  be  determined  by  the  types  of  IGES  en- 
tities required  by  the  AGS/880  IGES  postprocessor.  This  is  because  each  item 
of  mechanical  part/product  drawing  information  must  be  dispersed  when  it  is 
translated  by  the  AGS/880  IGES  postprocessor,  due  to  the  variables  associated 
with  the  ICC  syntax. 

The  fifth  rectangle  in  Figure  4 represents  the  translated  mechanical  part/product  draw- 
ing information  in  the  AGS/880  system.  The  purpose  of  this  format  step  is  to  repre- 
sent the  information  in  the  AGS/880  system  in  the  same  way  as  if  it  were  created  on 
the  AGS/880  system.  Again,  the  ICC  syntax  and  semantics  for  this  format  step  are  con- 
tained in  a document  called  General  CAD  Practices  and  File  Standards  for  the 
AGS/880  system.  The  ICC  syntax  and  semantics  for  this  format  step  define: 

syntax  - the  choice  of  the  format  and  structure  for  creating  and  manipulating 
each  item  of  mechanical  part/product  drawing  information  using  the  user  inter- 
face available  on  the  AGS/880  system. 

semantics  - what  each  item  of  mechanical  part/product  drawing  information  that 
is  to  be  created  and  manipulated  means  for  the  mechanical  part/product  draw- 
ing application. 


The  four  circles  in  Figure  4 represent  the  software  units  that  must  perform  the  trans- 
lation of  mechanical  part/product  drawing  information.  The  translation  occurs  from 
the  CAD  database  format  for  the  AGS/880  system  through  the  Department  of  Energy 
Data  Exchange  Format,  to  the  CAD  database  format  for  the  AGS/880  system.  SCC 
has  been  imposed  by  requiring  that  two  of  these  software  units,  the  AGS/880  Deflavor 
Translator  and  the  AGS/880  Reflavor  Translator,  be  written  on  the  basis  of  the  ICC 
syntax  and  semantics  defined  in  the  documentation  above. 

The  first  circle  in  Figure  4 represents  the  "generic"  IGES  preprocessor  for  the  AGS/880 
system.  This  software  unit  translates  the  mechanical  part/product  drawing  information 
from  the  AGS/880  system  into  the  IGES  format.  The  IGES  preprocessor  was  original- 
ly supplied  by  Applicon-Schlumberger,  the  vendor  of  AGS/880  system.  The  software 
unit  is  based  only  on  the  capabilities  of  the  AGS/880  system  and  the  system  structure. 
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This  IGES  preprocessor  was  partially  rewritten  at  Sandia  using  the  originally  supplied 
software  as  a basis. 

The  syntax  for  the  "mapping"  of  information  from  the  AGS/880  system  into  the  IGES 
format  is  based  on  the  syntax  of  the  AGS/880  database  format  and  the  IGES  format. 
The  analysis  of  how  the  information  is  translated  and  dispersed  into  the  IGES  entities 
provided  the  basis  for  documenting  the  mappings  for  this  software.  Many  of  these  map- 
pings are  contained  in  a document  called  Requirements  for  the  Applicon  AGS/880 
IMAGE  CAD  System  Deflavor  Translator. 

The  second  circle  in  Figure  4 represents  the  AGS/880  Deflavor  Translator.  This 
software  unit  translates  mechanical  part/product  drawing  information  from  the  IGES 
format  to  the  Department  of  Energy  Data  Exchange  Format.  This  software  unit  was 
written  using  the  knowledge  of  the  ICC  syntax  and  semantics  contained  in  several  docu- 
ments: (a)  the  General  CAD  Practices  and  File  Standards  document  for  the  AGS/880 
system,  (b)  the  ICC  syntax  contained  in  the  Initial  Graphics  Exchange  Specification, 
and  (c)  the  ICC  syntax  and  semantics  contained  in  the  Department  of  Energy  Data  Ex- 
change Format. 

The  ICC  syntax  and  semantics  specified  by  these  documents,  plus  the  mappings  docu- 
mented for  the  IGES  preprocessor  in  Requirements  for  the  Applicon  AGS/880 
IMAGE  CAD  System  Deflavor  Translator,  provided  the  knowledge  to  document  the 
necessary  mappings  from  the  IGES  Format  to  the  Department  of  Energy  Data  Ex- 
change Format.  The  mappings  are  included  in  Requirements  for  the  Applicon 
AGS/880  IMAGE  CAD  System  Deflavor  Translator.  The  AGS/880  Deflavor  Trans- 
lator implements  these  mappings  to  prepare  the  mechanical  part/product  drawing  in- 
formation as  defined  in  the  Department  of  Energy  Data  Exchange  Format. 

The  third  circle  in  Figure  4 represents  the  AGS/880  Reflavor  Translator.  This  software 
unit  translates  mechanical  part/product  drawing  information  from  the  Department  of 
Energy  Data  Exchange  Format  to  the  IGES  format.  This  software  unit  was  written 
using  the  knowledge  of  the  ICC  syntax  and  semantics  contained  in  several  documents: 
(a)  the  General  CAD  Practices  and  File  Standards  for  the  AGS/880  system,  (b)  the  ICC 
syntax  contained  in  the  Initial  Graphics  Exchange  Specification,  and  (c)  the  ICC  syn- 
tax and  semantics  contained  in  the  Department  of  Energy  Data  Exchange  Format. 

The  ICC  syntax  and  semantics  specified  by  these  documents,  plus  the  mappings  docu- 
mented for  the  IGES  postprocessor  in  Requirements  for  the  AGS/880  IMAGE  CAD 
System  Reflavor  Translator,  provided  the  knowledge  to  document  the  necessary  map- 
pings from  the  Department  of  Energy  Data  Exchange  Format  to  the  IGES  Format. 
The  mappings  are  included  in  Requirements  for  the  Applicon  AGS/880  IMAGE  CAD 
System  Reflavor  Translator.  The  AGS/880  Reflavor  Translator  implements  these 
mappings  to  read  the  mechanical  part/product  drawing  information  from  the  Depart- 
ment of  Energy  Data  Exchange  Format. 


32 


The  fourth  circle  in  Figure  4 represents  the  "generic"  IGES  postprocessor  for  the 
AGS/880  system.  This  software  unit  translates  the  mechanical  part/product  drawing 
information  from  the  IGES  format  to  the  CAD  database  format  of  the  AGS/880  sys- 
tem. The  IGES  postprocessor  was  originally  supplied  by  Appiicon-Schlumberger,  Inc., 
the  vendor  of  the  AGS/880  system.  The  software  unit  is  based  only  on  the  capabilities 
of  the  system  and  the  system  structure.  This  IGES  postprocessor  was  partially  rewrit- 
ten using  the  original  software  as  a basis. 

The  syntax  for  the  "mapping"  of  information  from  the  IGES  format  to  the  CAD 
database  format  of  the  AGS/880  system  is  based  on  the  syntax  of  the  CAD  database 
format  for  the  AGS/880  system  and  the  IGES  format.  The  mappings  implemented  in 
this  software  unit  are  based  on  reversing  the  mappings  implemented  by  the  IGES 
preprocessor.  Therefore,  the  structure  of  the  mechanical  part/product  drawing  infor- 
mation must  be  identical  to  the  structure  that  resulted  from  the  work  of  the  IGES 
preprocessor.  The  knowledge  of  the  necessary  CAD  information  structure  for  the  IGES 
postprocessor  makes  it  possible  to  document  the  necessary  mappings  for  the  AGS/880 
Reflavor  Translator. 

After  considering  the  single  example  above,  it  is  clear  that  a comprehensive  approach 
for  ICC  and  SCC  is  necessary  to  successfully  implement  an  AP  process. 

Currently,  users  have  only  one  option  for  the  implementation  of  an  AP  process,  the 
structure  shown  in  Figure  2.  To  successfully  implement  an  AP  process  based  on  the 
structure  shown  in  Figure  2,  the  user  must  first  become  familiar  with  the  CAD  system 
and  the  vendor  supplied  IGES  translators.  This  knowledge  is  necessary  to  develop  the 
ICC  documentation  for  information  creation  and  translation.  The  user  must  then 
prepare  the  AP  format  translators  based  on  the  ICC  documentation. 

Presently,  users  must  do  the  entire  job  of  developing  and  implementing  AP  processes. 
When  approved  IGES  APs  exist,  options  will  also  exist  for  the  development  of  AP 
processes  using  vendor  supplied  AP  format  translators. 

For  example,  if  an  approved,  "standardized"  IGES  AP  did  exist,  a contractor  or  vendor 
could  complete  the  implementation  work.  Specifically,  a CAD  system  vendor  could  be 
contracted  by  a user  to  develop  both  the  ICC  documentation  and  the  AP  format  trans- 
lators. This  would  allow  users  to  purchase  a "ready  made"  AP  process  based  on  the 
structure  in  Figure  3. 

Finally,  for  any  AP  process,  either  user  developed  or  purchased,  users  must  become 
familiar  with  their  ICC  documentation  for  information  creation,  manipulation,  and 
translation.  A successful  AP  process  will  always  require  that  users  implement  and  fol- 
low ICC  policies  and  procedures. 
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4.2  Example  of  a Simple  Application  Protocol 


This  section  provides  an  introduction  to  an  example  AP  for  Feature  Control  Frames. 
This  example  will  look  at  one  small  portion  of  the  domain  that  a complete  AP  for  the 
drafting  application  would  encompass. 

The  mission  of  the  drafting  application  is  to  prepare  detailed  renderings  of  the  neces- 
sary information  about  a product  (part,  assembly,  or  sub-assembly)  so  that  it  can  be 
used  to  analyze  or  manufacture  the  product.  The  first  step  in  accomplishing  this  mis- 
sion is  to  accept  the  geometry,  features,  dimensions,  tolerances,  and  other  necessary 
information  as  input  from  designers,  engineers,  etc.,  and  to  determine  the  best  way  to 
present  the  information  on  a traditional  paper  drawing  sheet.  The  second  step  in  ac- 
complishing this  mission  is  to  actually  prepare  the  rendering,  subject  to  procedures, 
standards,  and  rules  that  are  intended  to  make  the  resulting  drawings  more  consistent 
and  easier  to  understand. 

In  the  drafting  application,  a Feature  Control  Frame  is  a means  of  conveying  the 
geometric  tolerance  information  for  an  individual  feature  on  a drawing.  The  Feature 
Control  Frame  is  one  aspect  of  the  rendering  of  dimensions  and  tolerances  that  has 
been  standardized  to  make  drawings  more  consistent.  The  rendering  of  a Feature  Con- 
trol Frame  includes  the  use  of  graphics,  numerals,  text,  and  symbols  to  represent  the 
information  about  a geometric  tolerance.[8]  A typical  Feature  Control  Frame  is  il- 
lustrated in  Figure  5. 
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This  example  contains  the  required  technical  content  for  an  AP  as  described  in  Section 
3.1.  As  per  Section  3.1,  the  required  technical  content  consists  of  an  Application 
Protocol  Information  Model  (APIM)  with  its  supporting  documentation,  an  applica- 
tion protocol  format  specification  (APFS),  and  a set  of  application  protocol  format  test 
cases. 

The  Application  Protocol  Information  Model  for  Feature  Control  Frames  is  given  in 
Appendix  B.l  and  consists  of  three  models,  the  Application  Reference  Model  (ARM), 
the  Application  Implementation  Model  (AIM),  and  the  Application  IGES  Implemen- 
tation Model  (AIIM).  The  supporting  documentation  for  the  APIM  is  also  given  in 
Appendix  B.l  and  consists  of  the  NLAM  object  definitions  and  the  business  rules  for 
the  APIM. 

The  NLAM  model  constraints  are  given  on  the  graphical  NIAM  diagrams  of  Figures 
B1-B4.  In  general,  the  business  rules  give  an  explanation  of  the  context  of  the  APIM. 
For  the  Feature  Control  Frame,  the  basis  of  the  APIM  is  the  American  National  Stand- 
ards Institute’s  Y14.5M  (1982)  Standard  for  Dimensioning  and  Tolerancing.  No 
acronyms  and  abbreviations  were  used  in  the  APIM.  No  assumptions  were  made  that 
affect  the  structure  or  information  content  of  the  APIM. 

See  Appendix  B for  the  complete  Feature  Control  Frame  example. 

In  summary,  in  a complete  AP  for  the  drafting  application,  this  example  would  be  only 
one  small  portion.  Other  portions  would  be  included  to  handle  other  information  such 
as  dimensions  and  manufacturing  information.  This  example  is  intended  to  illustrate 
how  each  small  portion  of  an  application  domain  can  be  addressed  individually,  and 
that,  when  taken  together,  all  of  the  small  portions  can  be  used  to  build  the  complete 
AP. 


4.3  User,  Implementor,  and  Purchaser  Views  of  Application 
Protocols 


Section  2.2  provided  a discussion  about  the  creation,  exchange,  and  archival  storage  of 
product  definition  data  (PDD)  in  the  form  of  digital  data  sets.  That  discussion  ex- 
amined these  aspects  of  digital  PDD  from  three  perspectives:  the  User,  Implementor, 
and  Purchaser  perspectives. 

This  section  will  examine  the  same  three  perspectives  of  the  use  of  IGES  APs  for 
producing  and  reading  digital  PDD.  Additionally,  this  section  will  present  some  con- 
clusions about  the  requirements  for  implementing  APs  in  software  systems  and  for 
producing  and  reading  digital  PDD  using  AP-based  processes. 

The  User  perspective  of  APs  is  the  viewpoint  held  by  an  end-user  who  is  interested  in 
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building  an  A P process  to  produce  and  read  digital  PDD.  As  stated  in  Section  2.2,  each 
end-user  has  requirements  for  the  structure  and  content  of  digital  PDD,  and  these  re- 
quirements are  a function  of  the  User’s  discipline  and  application  area.  The  User’s  ob- 
jective is  to  build  an  AP  process  to  produce  and  read  AP  formatted  data  that  describes 
the  product  for  a certain  discipline. 

The  Implementor  perspective  is  the  viewpoint  held  by  an  individual  that  develops  sys- 
tems and  software  for  Users  that  must  develop  AP  processes.  For  APs,  the  objective 
of  the  Implementor  is  to  provide  software  systems  that  support  the  AP  information 
model  and  AP  format  translators  that  will  allow  the  User  to  implement  an  AP  process. 
The  Implementor  will  provide  the  initial  verification  of  the  software  components  for 
the  AP  processes. 

The  Implementor’s  main  requirement  for  developing  AP  systems  and  software  is  to 
have  a well-defined  and  stable  set  of  implementation  specifications.  These  implemen- 
tation requirements  are  given  by  the  AP  information  model  and  the  AP  format 
specification.  It  will  be  much  easier  to  develop  quality  systems  and  software  to  support 
the  AP  if  these  requirements  are  stable.  The  Implementor  cannot  guarantee  the 
capability  of  the  software  if  the  support  of  an  AP  requires  an  open-ended  development 
process. 

With  the  AP  software,  the  Implementor  will  provide  to  the  User  instructions  for  prepar- 
ing digital  PDD  in  AP  processes.  The  Implementor-supplied  instructions  must  be 
validated  in  conjunction  with  the  systems  and  software  for  use  in  AP  processes. 

The  Purchaser  perspective  is  the  viewpoint  held  by  an  individual  or  organization  that 
must  purchase  digital  PDD  along  with  the  products  themselves.  These  data  sets  will 
have  been  produced  by  User  developed  AP  processes  consisting  of  systems  and 
software  developed  by  Implementors.  The  Purchaser’s  primary  requirement  is  that  the 
data  sets  meet  the  specifications  of  the  validated  APs. 

The  Purchaser  will  be  dependent  on  the  correctness  of  the  AP  itself,  the  Users’  im- 
plementation of  the  AP  process  that  produced  the  data,  and  the  Implementors’  systems 
and  software  that  were  used  as  part  of  the  Users’  AP  process.  The  Purchaser  will  re- 
quire that  User  implementations  of  AP  processes  be  validated  before  the  Purchaser 
agrees  to  purchase  the  User’s  data.  In  addition,  the  Purchaser  may  require  that  User 
produced  data  sets  be  placed  in  long-term  archival  storage  for  future  retrieval  and  use 
with  User  developed  AP  processes.  The  Purchaser  will  be  dependent  on  the  valida- 
tion of  the  AP,  of  the  Implementors  support  of  the  AP,  and  of  the  User’s  AP  process. 

In  summary,  the  User,  Implementor,  and  Purchaser  have  different  views  of  APs  for  use 
in  producing  and  reading  digital  PDD.  The  User  must  be  able  to  build  AP  processes 
for  producing  and  reading  digital  PDD.  The  User  must  depend  on  Implementor 
developed  systems,  software,  and  documentation  to  build  the  AP  processes.  The  Im- 
plementor must  develop  systems,  software,  and  documentation  to  support  validated 
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APs  that  allow  the  User  to  build  AP  processes.  The  Implementor,  in  order  to  assist  the 
User  in  building  AP  processes,  must  develop  the  systems,  software,  and  documenta- 
tion according  to  stable  APs.  The  Purchaser  must  be  able  to  acquire  digital  PDD  in 
AP  formats,  produced  by  Users  with  AP  processes  that  include  Implementor  developed 
systems,  software,  and  documentation.  The  Purchaser  will  depend  on  both  Users  and 
Implementors  for  acquiring  complete  and  correct  AP  formatted  data  sets. 

Finally,  it  must  be  understood  that  the  specification,  validation,  and  implementation  of 
IGES  APs  will  in  many  cases  require  that  organizations  revise  their  policies  and  pro- 
cedures for  the  creation,  exchange,  and  archival  storage  of  product  data. 
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Appendix  A.  Glossary 


Application  - A specific  function  or  work  area  such  as  Design,  Drafting,  Analysis,  Test- 
ing, or  Manufacturing  that  contributes  to  realization  of  the  product  definition  data 
and/or  finished  product  deliverables  for  one  or  more  disciplines;  also,  any  one  of  a 
group  of  activities  that  is  a part  of  Design,  Drafting,  Analysis,  Testing,  or  Manufactur- 
ing such  as  Geometric  Modeling,  Finite  Element  Analysis,  Dynamic  Response  of  Ar- 
ticulated Machinery,  or  Numerical  Control  Machining.  The  nature  of  an  application 
may  differ  depending  on  several  factors,  one  of  which  is  the  discipline(s)  that  it  must 
support. 

Application  Area  - See  Application 

Application-based  view  - A means  of  interpreting  product  definition  data  that  is  based 
on  an  information  model  for  a specific  application.  In  application  protocols,  the  ap- 
plication protocol  information  model  provides  this  means  by  facilitating  the  interpreta- 
tion of  product  definition  data  using  the  application  area’s  terminology  and  rules.  This 
term  does  not  include  or  require  a completely  computer-understandable  repre- 
sentation of  the  application  protocol  information  model. 

Application  Implementation  Model  (AIM)  - An  information  model  that  is  directed 
towards  an  implementation  of  information  structures  for  a particular  application  area. 
The  information  model  is  based  on  an  application  reference  model  and  uses  applica- 
tion specific  terminology  and  rules.  The  information  model  also  contains  implemen- 
tation-based detail  that  is  necessary  to  specify  the  items  of  information  that  must  be 
identifiable  in  an  application  protocol  format. 

Application  IGES  Implementation  Model  (AIIM)  - An  information  model  that 
describes  the  information  structures  required  to  accomplish  an  implementation  using 
IGES  entities.  The  information  model  is  based  on  an  application  implementation 
model  and  is  prepared  at  a level  of  abstraction  that  is  appropriate  to  select  the  neces- 
sary IGES  entities  for  an  application  protocol  format. 

Application  Protocol  (AP)  - A method  to  achieve  consistent  and  reliable  exchange  of 
product  definition  data  within  a specified  application  area.  The  key  components  of  an 
application  protocol  are  a conceptual  information  model  for  the  application  area  with 
its  supporting  documentation,  an  application  protocol  format  specification,  and  a set 
of  application  protocol  format  test  cases. 

Application  Protocol  Format  (APF)  - An  application  specific  format  that  is  based  on 
the  embedding  of  items  of  information  from  a conceptual  information  model  into  IGES 
entities. 
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Application  Protocol  Format  Specification  (APFS)  - A specification  that  provides  a 
complete,  rigorously  defined,  and  unambiguous  means  to  represent  the  information 
that  is  required  for  a specific  application  area;  consists  of  an  application  subset,  the 
restrictions  on  the  global,  directory  entry,  and  parameter  data  sections,  and  a usage 
guide  for  the  application  subset. 

Application  Protocol  Format  Translator  - An  application  specific  translator  that  is 
based  on  the  imbedding  of  CAD  information  from  the  application  protocol  informa- 
tion model  into  the  CAD  database  format  and  the  IGES  entities  in  an  application 
protocol  format.  The  translator  implements  a single  mapping  association  between  a 
certain  entity  in  the  CAD  database  format  and  a certain  IGES  entity  (APF  preproces- 
sor), or  between  a certain  IGES  entity  and  a certain  entity  in  the  CAD  database  for- 
mat (APF  postprocessor)  to  satisfy  the  needs  of  one  application  protocol  and  its  as- 
sociated application  protocol  format. 

Application  Protocol  Information  Model  (APIM)  - A set  of  information  models  that 
are  developed  for  an  application  protocol.  The  information  models  are  an  application 
reference  model,  an  application  implementation  model,  and  an  application  IGES  im- 
plementation model. 

Application  Protocol  Usage  Guide  - A set  of  instructions  describing  how  the  IGES  en- 
tities from  the  application  subset  are  to  be  used  to  carry  the  information  described  in 
the  conceptual  information  model.  The  usage  guide  is  one  required  component  of  the 
Application  Protocol  Format  Specification. 

Application  Protocol  Validation  - The  evaluation  of  a candidate  application  protocol, 
including  the  constituent  components  (refer  to  Application  Protocol)  to  confirm  its 
suitability.  The  goal  of  the  evaluation  is  to  ensure  that  all  of  the  necessary  information 
requirements  are  supported  by  the  candidate  application  protocol.  See  Validation. 

Application  Reference  Model  (ARM)  - An  information  model  that  describes  the  infor- 
mation requirements  and  the  information  structure  for  an  application  area.  The  infor- 
mation model  uses  application  specific  terminology  and  rules  familiar  to  an  expert  from 
the  application  area.  The  model  is  independent  of  any  physical  implementation  and 
can  be  validated  by  an  expert  from  the  application  area.  See  Validation. 

Application  Subset  - An  unambiguous  set  of  IGES  entities  which  span  the  data  require- 
ments of  the  specified  application.  The  set  of  IGES  entities  is  determined  on  the  basis 
of  the  Application  Protocol  Information  Model  (APIM).  The  documentation  for  an 
Application  Subset  is  required  as  part  of  the  Application  Protocol  Format  Specifica- 
tion (APFS). 
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Application  Validation  Methodology  (AVM)  Committee  - A technical  committee  of 
the  IGES/PDES  Organization  which  is  developing  guidelines  and  methods  to  achieve 
consistent  and  reliable  exchanges  of  product  definition  data  within  a specified  applica- 
tion area.  This  committee  is  also  developing  the  methodology  to  validate  candidate 
implementations  of  these  product  definition  data  exchange  methods. 

Application  Validation  - The  systematic  investigation  of  a system  or  software  capability 
to  determine  whether  it  fulfills  the  requirements  of  a specific  application  area. 

Application  Validation  Testing  - See  Application  Validation 

Computer-Aided  Design  (CAD)  System  - A unified  collection  of  computer  hardware 
and  software  whose  purpose  is  to  facilitate  the  creation,  storage,  distribution,  and  use 
of  product  definition  data  in  digital  form. 

Conceptual  Information  Model  - A description  of  the  information  requirements,  in- 
formation structure,  and  the  relationships  between  the  individual  items  of  information 
for  an  application  area.  Models  are  usually  developed  using  a formalized,  graphical 
modeling  language,  such  as  NIAM  or  IDEF1X. 

Discipline  - An  area  or  field  of  endeavor  such  as  Mechanical  Products,  Electrical 
Products,  or  Architecture,  Engineering,  and  Construction,  that  has  as  its  deliverable 
both  product  definition  data  and  finished  products.  The  structure  and  content  of 
product  definition  data  and  the  configuration  of  finished  products  for  each  discipline 
are  a function  of  the  discipline  itself. 

Entity  - The  basic  unit  of  data  in  an  IGES  file.  The  term  applies  to  single  units  which 
may  be  individual  elements  of  geometry,  individual  elements  of  annotation,  or  collec- 
tions of  geometry  or  annotation  elements  that  are  combined  to  form  more  complex 
data  structures. 

Generic  IGES  Translator  - An  application  independent  IGES  translator  that  imple- 
ments a set  of  mappings  for  CAD  information  from  the  CAD  database  format  of  a cer- 
tain CAD  system  to  the  IGES  format  (IGES  preprocessor),  or  from  the  IGES  format 
to  the  CAD  database  format  of  a certain  CAD  system  (IGES  postprocessor).  The  trans- 
lator implements  a single  mapping  association  between  an  entity  in  the  CAD  database 
format  and  an  entity  in  the  IGES  format,  or  vice  versa.  The  single  mapping  association 
is  based  on  the  similarity  of  CAD  database  format  and  IGES  format  data  structures. 

IGES  Postprocessor  - A software  unit  that  translates  CAD  data  from  the  IGES  format 
to  the  CAD  database  format  of  a certain  CAD  system.  The  software  is  usually 
developed  and  maintained  by  a commercial  CAD  system  vendor. 
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IGES  Preprocessor  - A software  unit  that  translates  CAD  data  from  the  CAD  database 
format  of  a certain  CAD  system  to  the  IGES  format.  The  software  unit  is  usually 
developed  and  maintained  by  a commercial  CAD  system  vendor. 

IGES  Application  Protocol  Format  Test  Cases  - IGES  data  files  of  product  definition 
data  that  meet  all  of  the  representational  requirements  of  information  for  the  applica- 
tion protocol.  The  files  must  be  prepared  such  that  they  are  in  compliance  with  the  ap- 
plication protocol  format  specification. 

Information  Model  - See  Conceptual  Information  Model 

Information  Configuration  Control  (ICC)  - An  approach  that  consists  of  specifying, 
documenting,  and  controlling  both  the  creation  of  information  and  the  subsequent 
translation  and  exchange  of  the  information  between  different  systems  and  formats. 
The  approach  requires  substantial  documentation  for  both  the  syntax  (the  format)  and 
the  semantics  (the  meaning)  of  the  information  items  at  each  step  in  the  process. 

Product  Data  - The  set  of  data  elements  that  are  necessary  to  provide  full  support  for 
a product  and  meet  all  of  its  in-service  needs  over  its  expected  life  cycle.  This  set  of 
data  elements  includes  all  of  the  product  definition  data  plus  other  data  pertaining  to 
the  operation  and  maintenance  of  the  product  until  it  is  removed  from  service. 

Product  Definition  - See  Product  Definition  Data 

Product  Definition  Data  - The  set  of  data  elements  that  completely  define  a product 
for  a certain  discipline.  This  set  of  data  elements  includes  the  geometry,  topology,  fea- 
tures, tolerances,  and  relationships  to  completely  define  a component  part  or  an  as- 
sembly of  parts.  The  data  is  structured  such  that  it  can  be  used  by  one  or  more  applica- 
tions. 

Protocol  - A set  of  rules  that  govern  the  operation  of  functional  units  to  achieve  com- 
munication. (ISO) 

Semantics  - The  meaning  that  is  given  or  assigned  to  an  item  of  information.  The  mean- 
ing is  assigned  to  an  item  of  information  on  the  basis  its  application  area. 

Syntax  - The  structure  and  organization  of  an  item  or  items  of  information,  as  in  a for- 
mat. The  format  is  described  in  a specification  such  as  IGES. 

Software  Configuration  Control  (SCC)  - An  approach  that  consists  of  controlling  the 
capability  and  make-up  of  software  systems  and  individual  software  units  through  the 
use  of  requirements.  For  information  creation,  translation,  and  exchange,  the  software 
requirements  are  prepared  from  ICC  documentation. 
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User  Interface  - The  set  of  commands,  menu  choices,  utilities,  and  options  that  exist  to 
create  and  edit  information  in  a CAD  system’s  database. 

Validation  - The  process  of  evaluating  software  at  the  end  of  the  software  development 
process  to  ensure  compliance  with  software  requirements.  (ANSI/IEEE  Std  729-1983) 

Validation  Criteria  - The  properties  of  an  application  protocol  that  will  be  investigated 
to  determine  success  or  failure  in  the  validation  of  a candidate  application  protocol. 
See  Validation. 

Verification  - The  process  of  determining  whether  or  not  the  products  of  a given  phase 
of  the  software  development  cycle  fulfill  the  requirements  established  during  the  pre- 
vious phase.  (ANSI/IEEE  Std  729-1983) 
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Appendix  B.l 


FEATURE  CONTROL  FRAMES  - APPLICATION  PROTOCOL  INFORMATION  MODEL 


This  Appendix  will  describe  the  Application  Protocol  Information  Model 
(APIM)  for  Feature  Control  Frames.  The  APIM  consists  of  three  information 
models,  the  Application  Reference  Model  (ARM),  the  Application 
Implementation  Model  (AIM) , and  the  Application  IGES  Implementation  Model 
(AIIM) . These  three  models  describe  the  information  requirements  and 
logical  structure  of  the  information  for  Feature  Control  Frames. 

The  Feature  Control  Frames  ARM  represents  the  Drafting  information  that  is 
required  for  a Feature  Control  Frame.  This  ARM  is  a part  of  the  complete 
Drafting  APIM.  The  ARM  is  a model  of  Feature  Control  Frames  information 
that  can  be  validated  by  a Drafting  application  area  expert.  The  ARM  is 
given  in  Figure  Bl.  The  supporting  documentation  for  this  model  is  given  at 
the  end  of  this  Appendix. 

From  Figure  Bl , the  Feature  Control  Frame  contains  the  Geometric 
Characteristic,  the  Tolerance  Specification,  the  Maximum  Tolerance  Value 
Specification,  and  the  Datum  Reference.  Also,  the  Feature  Control  Frame 
belongs  to  a Feature  Relationship,  is  represented  by  a Frame  Box,  and  is 
compartmentalized  by  a Frame  Box  Divider. 

From  Figure  Bl,  the  Tolerance  Specification  contains  the  Tolerance 
Cylindrical  Form,  the  Tolerance  Value,  the  Tolerance  Material  Condition,  the 
Tolerance  Unit  Length,  and  the  Tolerance  Unit  Width.  The  Maximum  Tolerance 
Value  Specification  contains  a Tolerance  Cylindrical  Form  and  a Maximum 
Tolerance  Value.  The  Datum  Reference  contains  a Datum  Identifier  and  a 
Datum  Material  Condition.  The  Feature  Relationship  contains  a Feature  and  a 
Feature  Relator.  The  Feature  Relator  can  be  one  of  four  types,  a Leader,  a 
Plane  Surface  Extension,  a Dimension  of  Size,  and  a Leader  Directed  Callout. 
The  Frame  Box  is  defined  by  four  coordinate  pairs.  The  Frame  Box  Divider  is 
defined  by  two  coordinate  pairs. 

The  Feature  Control  Frames  ARM  of  Figure  Bl  describes  the  information 
requirement  and  structure  for  the  Feature  Control  Frame  - Feature  Relationship 
part  of  Feature  Control  Frames.  For  simplicity,  this  Feature  Control  Frames 
Application  Protocol  example  will  not  implement  this  information  requirement. 

Figure  B2  illustrates  the  initial  AIM.  The  initial  AIM  was  developed  on  the 
basis  of  the  ARM  and  shows  the  Drafting  information  for  Feature  Control 
Frames  that  must  be  "identifiable"  in  the  IGES  entities  in  the  Drafting  APF. 
The  meaning  of  "identifiable"  in  this  context  is  that  it  must  be  possible  to 
have  a reversible  mapping  of  Feature  Control  Frames  information  from  the  ARM 
into  the  IGES  entities  in  the  APF.  The  initial  AIM  provides  a description 
of  the  way  that  the  Feature  Control  Frames  information  must  be  structured  to 
allow  an  explicit  reversible  mapping.  The  initial  AIM  contains  the  same 
application-based  information  requirements  and  structure  as  the  ARM,  but 
also  contains  additional  implementation-based  identifiers  for  the 
information  requirements. 
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From  Figure  B2 , the  Feature  Control  Frame  is  identified  by  a Feature  Control 
Frame  Identifier.  The  Geometric  Tolerance  is  identified  by  a Geometric 
Tolerance  Identifier.  The  Geometric  Characteristic  is  represented  by  a 
Geometric  Characteristic  Symbol.  The  Tolerance  Specification  is  identified 
by  a Tolerance  Specification  Identifier.  The  Tolerance  Cylindrical  form  is 
represented  by  a Diameter  Symbol.  The  Tolerance  Value  is  represented  by  a 
Tolerance  Value  String.  The  Tolerance  Material  Condition  is  represented  by 
a Material  Condition  Symbol.  The  Tolerance  Unit  Length  is  represented  by  a 
Tolerance  Unit  Length  String.  The  Tolerance  Unit  Width  is  represented  by  a 
Tolerance  Unit  Width  String. 

From  Figure  B2 , the  Maximum  Tolerance  Value  Specification  is  identified  by  a 
Maximum  Tolerance  Specification  Identifier.  The  Maximum  Tolerance  Value  is 
represented  by  a Maximum  Tolerance  Value  String.  The  Datum  Reference  is 
identified  by  a Datum  Reference  Identifier.  The  Datum  Identifier  is 
represented  by  a Datum  Identifier  String.  The  Datum  Material  Condition  is 
represented  by  a Datum  Material  Condition  Symbol.  The  Frame  Box- 
Coordinate  Pair  consists  of  an  X Value  and  a Y Value.  The  Frame  Box  is 
identified  by  a Frame  Box  Identifier.  The  Frame  Box  Divider-Coordinate  Pair 
consists  of  an  X Value  and  a Y Value.  The  Frame  Box  Divider  is  identified  by 
a Frame  Box  Divider  Identifier. 

As  previously  discussed,  the  initial  AIM  contains  implementation-based 
identifiers  for  the  information  requirements  from  the  ARM.  Several 
implementation  constraints  were  used  in  this  Feature  Control  Frames  AP 
example.  These  constraints  were  imposed  to  make  the  specification  of  the  AP 
format  possible  without  major  revisions  and  enhancements  to  the  IGES 
Specification.  These  constraints  are  given  below. 

Constraint  1 - The  Application  Protocol  Format  Specification  must  use 
IGES  entities  that  exist  in  the  current  IGES  Specification,  where 
possible.  It  is  permissible  to  define  new  IGES  entities  only  where  there 
is  no  existing  IGES  entity  that  can  be  used  to  carry  the  necessary  information. 

Constraint  2 - The  IGES  entities  selected  for  use  in  the  Application 
Protocol  Format  Specification  must  be  selected  so  as  to  minimize  the  size 
of  AP  format  files  as  much  as  possible.  This  means  that  the  ''simplest" 
IGES  entity  should  be  selected  when  there  is  more  than  one  possible  choice. 

Because  of  the  implementation  constraints  given  above,  decisions  and  trade- 
offs had  to  be  made  about  the  final  IGES  entity  selections  for  this  Feature 
Control  Frames  example.  This  decision  process  resulted  in  a final  AIM  that 
provides  a less  explicit  "identification"  of  each  item  of  Feature  Control  Frames 
information  in  the  APF  entities.  For  the  implementation  described  by  the 
APFS  in  Appendix  B.2,  the  Tolerance  Specification  Identifier,  the  Maximum 
Tolerance  Specification  Identifier,  and  the  Datum  Reference  Identifier  had 
to  be  eliminated  to  produce  the  final  AIM.  The  final  AIM  is  illustrated  in 
Figure  B3 . In  reality,  Figure  B3  shows  that  it  will  not  be  possible  to  have 
an  explicit  reversible  mapping  of  Feature  Control  Frames  information  into 
and  out  of  the  APF.  It  is  possible  to  accomplish  a reverse  mapping  of  the  Feature 
Control  Frames  information,  but  the  reverse  mapping  must  be  made  without  the 
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explicit  identifiers. 


The  AIIM  is  illustrated  in  Figure  B4.  The  AIIM  is  a model  of  the  logical 
structure  of  Feature  Control  Frames  information  after  it  has  been  abstracted 
to  an  appropriate  level  for  use  in  selecting  the  necessary  IGES  entities  to 
carry  the  information.  This  AIIM  was  developed  on  the  basis  of  the  initial 
AIM. 

From  Figure  B4,  a Feature  Control  Frame  is  a sub -type  of  Drafting 
Annotation.  Drafting  Annotation  must  be  identified  by  an  Annotation 
Identifier.  Drafting  Annotation  must  be  comprised  of  two  or  more  Linear 
Curves  and  two  or  more  Drafting  Components.  The  Linear  Curve  must  be 
identified  by  a Component  Identifier.  The  Linear  Curve  must  be  one  of  two 
types,  a Line  or  a Copious  Linear  Curve.  The  Drafting  Component  must  be 
identified  by  a Component  Identifier.  The  Component  must  be  signified  by  a 
Symbol  or  a String.  Figure  B4  illustrates  the  logical  structure  for  the 
Drafting  Annotation- Feature  Control  Frame -Geometric  Tolerance.  This  logical 
structure  will  not  be  implemented  in  this  example. 

The  AIIM  of  Figure  B4  also  illustrates  the  logical  structure  for  the  Feature 
Control  Frame-Feature  Relationship  structure  from  Figure  B1  in  the  Drafting 
Annotation-Feature  Relationship.  This  logical  structure  will  not  be 
implemented  in  this  AP  example  for  Feature  Control  Frames.  As  stated  above, 
this  AIIM  was  developed  on  the  basis  of  the  initial  AIM.  As  discussed 
previously,  the  final  AIM  was  developed  on  the  basis  of  implementation  decisions 
and  trade-offs  that  resulted  in  the  elimination  of  several  identifiers.  The 
"X-Outs"  in  Figure  B4  represent  the  elimination  of  logical  identifiers  in 
the  AIIM  as  was  done  in  the  final  AIM. 

The  AIIM  of  Figure  B4  was  used  to  select  the  IGES  General  Symbol,  General 
Note,  Simple  Closed  Area,  and  Line  entities  for  use  in  carrying  the  Feature 
Control  Frames  information  in  the  AP  format.  Appendix  B.2,  the  Application 
Protocol  Format  Specification,  will  describe  the  example  Application 
Protocol  Format  for  Feature  Control  Frames. 
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NIAM  Modeling  Guide  for  Information  Analysis 


fHOLOfl 

HW4E 


NON-LEXICAL  OBJECT  TYPE  (NOLOT):  CLASSES  OF  NON-LEXICAL 

OBJECTS  UKE  PERSON,  TOWN,  ETC. 


LEXICAL  OBJECT  TYPE  (LOT):  CLASSES  OF  LEXICAL  OBJECTS  UKE 

SURNAME,  TOWN-NAME,  ETC. 


HAS 


IS  OF 


4 


<D 


(A>^ 


HAS 


IS  OF 


HAS 


IS  OF 


HAS 


IS  OF 


1 1 2 

EVERY  "A"  HAS  ONE  Sc  ONLY  ONE  "B" 

4 3 

A "B“  IS  OF  ZERO,  ONE  OR  MANY  "A" 

1 1 2 
AN  "A"  MAY  HAVE  ZERO  OR  ONE  "B" 

4 3 

A "B"  IS  OF  ZERO,  ONE  OR  MANY  "A" 

1 2 

AN  "A"  HAS  ZERO,  ONE  OR  MANY  "B" 

3 2 

A "B"  IS  OF  ZERO,  ONE  OR  MANY  "A" 

1 1 2 

EVERY  "A"  HAS  ONE  OR  MANY  ,,BU 

3 2 

A "B"  IS  OF  ZERO,  ONE  OR  MANY  “A" 

1 2 

AN  "A"  HAS  ZERO  OR  ONE  "B" 

4 3 

A "B"  IS  OF  ZERO  OR  ONE  "A" 

1 1 2 

EVERY  "A"  HAS  ONE  & ONLY  ONE  MB" 

4 3 

A "B"  IS  OF  ZERO  OR  ONE  "A" 

1 1 2 

EVERY  "A"  HAS  ONE  Sc  ONLY  ONE  “B" 

4 4 3 

EVERY  UB"  IS  OF  ONE  Sc  ONLY  ONE  "AM 

1 1 2 
AN  "A"  MAY  HAVE  ZERO  OR  ONE  "B" 

4 3 

A "B"  IS  OF  ONE  OR  MANY  “A" 


THERE  IS  AN  ENTITY  KNOWN  AS  “A". 
"A"  IS  AN  OBJECT  OR  A CONCEPT. 


BRIDGE  WHICH  RELATES  A NONLEXICAL  OBJECT 
TO  A LEXICAL  OBJECT  THROUGH  ROLES  R1  3c  R2. 


THERE  IS  AN  ENTITY  KNOWN  AS  "B". 

"B"  IS  A LEXICAL  REPRESENTATION  OF  "A". 


IDEA  WHICH  RELATES  TWO  NONLEXICAL  OBJECTS 
THROUGH  ROLES  R1  AND  R2. 


7"^  THE  OBJECT  "A"  OCCURS  ELSEWHERE 

ON  THIS  OR  ANOTHER  NIAM  DIAGRAM. 


"B"  IS  A SUBSET  OF  "A". 


TOTAL  CONSTRAINT. 

ALL  OF  THE  MEMBERS  OF  "A"  ARE 
CONTAINED  IN  SUBSETS  "B",  "C" 
AND  "D".  THERE  ARE  NO  OTHER 
SUBSETS  OF  "A". 
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EXCLUSION  CONSTRAINT. 

"B",  "C"  AND  "DM  ARE  DISJOINT 
SUBSETS  OF  “A". 


“ONE  AND  ONLY  ONE1*  CONSTRAINT. 
"B'\  "C"  AND  "D"  ARE  DISJOINT 
SUBSETS  OF  "A"  AND  THERE  ARE 
NO  OTHER  SUBSETS  OF  "A". 


UNIQUENESS  CONSTRAINT. 
ENTITIES  "B"  AND  "C"  ARE 
BOTH  REQUIRED  TO  UNIQUELY 
IDENTIFY  "A11. 


EQUALITY  CONSTRAINT. 

ALL  MEMBERS  OF  "A"  THAT  ARE 
RELATED  TO  "8“  THROUGH  ROLE  R1 
ALSO  ARE  RELATED  TO  "C"  THROUGH 
ROLE  R2. 


EXCLUSION  CONSTRAINT. 

ANY  “A"  THAT  IS  RELATED  TO  "B" 
THROUGH  ROLE  R1  CANNOT  BE 
RELATED  TO  MC"  THROUGH  ROLE  R2 
AND  VICE  VERSA. 
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Application  Protocol  Information  Model  Supporting  Documentation 


I.  Application  Reference  Model  (ARM)  Object  Definitions 


Datum  - the  origin  of  the  dimensional  relationship  between  a toleranced 
feature  and  a designated  feature  on  a part. 

Datum  Identifier  - indicates  a specified  Datum;  indicated  by  an  alphabetic 
letter,  such  as  A,  B,  etc. 

Datum  Material  Condition  - the  relative  limit  of  size  condition  of  the 

designated  feature  that  is  to  be  used  as  the  datum  in  the  dimensional  relationship. 

Feature  Control  Frame  - the  means  used  in  Drafting  to  specify  a geometric 
tolerance  that  consists  of  geometric  characteristic  symbols,  a tolerance 
value,  and  datum  reference  letters;  where  appropriate,  other  conditions  on 
the  tolerance  are  expressed,  such  as  material  conditions,  a maximum 
tolerance  value,  and  a maximum  unit  length  or  unit  width. 

Frame  Box  - the  combined  horizontal  and  vertical  lines  that  make  up  the 

perimeter  of  the  complete  Feature  Control  Frame. 

Frame  Box  Divider  - the  vertical  lines  that  divide  the  Feature  Control  Frame 
into  compartments . 

Geometric  Characteristic  - the  aspect  of  the  part  feature  that  the  tolerance 
is  directed  to,  such  as  straightness,  flatness,  circularity,  etc.,  for  form 
tolerances,  or  position  for  positional  tolerances. 

Maximum  Tolerance  Value  - the  explicitly  specified  numerical  value  of  the 

maximum  deviation  from  the  specified  ideal  value. 

Maximum  Tolerance  Value  Specification  - the  explicit  enumeration  of  the 
maximum  deviation,  consisting  of  a Tolerance  Cylindrical  Form  specifier  and 
a Maximum  Tolerance  Value. 

Tolerance  Cylindrical  Form  - precedes  the  tolerance  value  in  a Feature 
Control  Frame  and  specifies  that  the  tolerance  gives  the  limit  on  the 
deviation  of  the  Geometric  Characteristic  relative  to  a cylindrical 
tolerance  zone. 

Tolerance  Value  - the  numerical  value  of  the  maximum  allowed  deviation  from 
the  specified  ideal  value. 

Tolerance  Material  Condition  - the  relative  limit  of  size  condition  of  the 
feature  for  which  the  Tolerance  Value  is  to  be  applied. 

Tolerance  Unit  Length  - the  numerical  value  of  the  length-wise  limit  on  the 
part  for  which  the  Tolerance  Value  gives  the  maximum  allowed  deviation  of 
the  Geometric  Characteristic. 
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Tolerance  Unit  Width  - the  numerical  value  of  the  width-wise  limit  on  the 
part  for  which  the  Tolerance  Value  gives  the  maximum  allowed  deviation  of 
the  Geometric  Characteristic;  when  combined  with  or  multiplied  by  the 
Tolerance  Unit  Length,  it  gives  the  size  of  the  unit  area  for  the 
application  of  the  Tolerance  Value. 

Tolerance  Specification  - the  enumeration  of  the  required  tolerance, 
consisting  of  at  least  the  Tolerance  Value;  may  also  consist  of  the 
Tolerance  Cylindrical  Form,  the  Tolerance  Material  Condition,  the  Tolerance 
Unit  Length,  and  the  Tolerance  Unit  Width. 


II.  Application  Reference  Model  (ARM)  Business  Rules 

1.  The  structure,  information  requirements,  and  drafting  representation  for 
a Feature  Control  Frame  are  given  in  the  ANSI  Standard  for  Dimensioning  and 
Tolerancing , ANSI  Y14.5M,  1982. [6] 
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Appendix  B.2 


FEATURE  CONTROL  FRAME  - APPLICATION  PROTOCOL  FORMAT  SPECIFICATION 


This  Appendix  consists  of  a sample  Drafting  Application  Protocol  Format 
Specification  (APFS)  for  Feature  Control  Frames.  This  APFS  example  consists 
of  the  required  technical  content  for  an  APFS,  including  the  Application 
Protocol  Format  (APF) . This  example  for  Feature  Control  Frames  gives  the 
IGES  entities,  the  restrictions  on  the  use  of  the  IGES  entities,  and  the 
usage  guide  for  the  IGES  entities  in  carrying  information  for  Feature  Control 
Frames . 

In  a complete  APFS,  this  section  would  be  only  a part  of  the  total  APFS  that 
would  be  required  to  give  the  complete  IGES  entity  set  for  the  AP , the 
restrictions  on  the  Global,  Directory  Entry,  and  Parameter  Data  sections  for 
the  AP , and  the  usage  guide  for  carrying  all  of  the  Drafting  information 
from  the  Application  Protocol  Information  Model  (APIM) . The  AP  Information 
Model  consists  of  three  information  models,  the  Application  Reference  Model 
(ARM) , the  Application  Implementation  Model  (AIM) , and  the  Application  IGES 
Implementation  Model  (AIIM) . These  three  information  models  are  required  to 
completely  describe  Feature  Control  Frames  for  the  purpose  of  developing  an 
APFS . 

For  maximum  utility  as  an  example  of  an  APFS,  this  APFS  will  include  an 
example  of  the  Global  section  restrictions  that  would  normally  be  included 
in  a complete  Drafting  APFS.  The  Global  section  restrictions  in  this 
example  are  not  based  on  the  Feature  Control  Frames  APIM. 


I.  IGES  Entity  Set 

The  IGES  entities  that  are  to  be  used  to  carry  Drafting  information  for 
Feature  Control  Frames  are  given  below.  These  entities  are  described  in  the 
Initial  Graphics  Exchange  Specification,  Version  3.0. [3]  These  IGES 
entities  were  selected  on  the  basis  of  the  final  Application  Implementation 
Model  (AIM)  and  the  Application  IGES  Implementation  Model  (AIIM)  from 
Appendix  B.l. 

228  - General  Symbol 
212  - General  Note 
106  - Simple  Closed  Area 
110  - Line 

The  General  Symbol  entity  was  selected  as  the  "associativity"  or  "grouping" 
entity  for  the  Feature  Control  Frame  because  it  supports  the  inclusion  of  a 
single  General  Note,  one  or  more  geometric  entities,  and  zero,  one  or  more 
Leaders.  These  are  the  basic  requirements  that  are  given  by  the  APIM  for 
Feature  Control  Frames. 

The  APIM  also  gives  basic  requirements  that  control  the  selection  of  the 
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individual  entities.  The  APIM  requires  the  use  of  multiple  text  strings  in 
a single  text  entity,  which  the  General  Note  entity  supports  with  no  problem. 

The  APIM  also  requires  the  use  of  four  grouped  straight  line  segments  for 
the  frame  box.  This  requirement  can  be  met  by  the  Simple  Closed  Area 
entity.  The  APIM  requires  a variable  number  of  individual  straight  line 
segments  for  the  variable  number  frame  box  dividers . This  requirement  can 
be  met  easily  through  the  use  of  Line  entities. 


II.  Global,  Directory  Entry,  and  Parameter  Data  Section  Restrictions 


This  section  gives  the  restrictions  on  the  Global,  Directory  Entry,  and 
Parameter  Data  section  restrictions  for  each  entity  in  the  IGES  entity  set. 
These  restrictions  were  specified  on  the  basis  of  the  final  AIM  and  the  AIIM 
from  Appendix  B.l. 

The  Global,  Directory  Entry,  and  Parameter  Data  section  restrictions  will  be 
given  separate  from  the  usage  guide  because  the  purpose  of  the  restrictions 
is  different  from  that  of  the  usage  guide.  The  purpose  of  the  restrictions 
is  to  reduce  the  possible  field  and  parameter  values  of  the  "general"  IGES 
entities  to  what  is  necessary  for  the  APF,  In  this  example  for  Feature 
Control  Frames,  the  restrictions  are  based  on  supporting  only  the  needs  of 
carrying  Feature  Control  Frame  information.  The  restrictions  are  based 
either  explicitly  or  implicitly  on  the  final  AIM  and  the  AIIM  from  Appendix 
B.l.  In  contrast,  the  usage  guide  for  the  IGES  entities  is  based  explicitly 
on  the  structure  and  meaning  expressed  in  the  ARM,  the  final  AIM,  and  the 
AIIM  and  specifies  how  the  Feature  Control  Frame  information  is  to  be 
carried  in  the  IGES  entities. 

In  a complete  APFS , as  in  this  example,  the  restrictions  would  be  based 
either  explicitly  or  implicitly  on  the  complete  APIM  so  that  the  needs  of 
the  APIM  would  be  supported  and  no  ambiguities  would  result.  As  in  this 
example,  the  restrictions  would  be  specified  for  each  of  the  entities  in  the 
IGES  entity  set. 

II. 1 Global  Section 


This  section  gives  the  Global  section  restrictions  for  the  APF.  As  stated 
above,  the  Global  section  restrictions  are  only  an  example  of  the  Global 
section  restrictions  that  would  normally  be  included  in  a complete  Drafting 
APFS.  These  restrictions  should  not  be  taken  as  a specification  of  the 
correct  restrictions  for  a Drafting  APFS.  The  Global  section  restrictions 
given  in  this  example  are  not  based  on  the  Feature  Control  Frames  APIM. 
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Global  Section  Field 


Parameter  Delimiter 
Record  Delimiter 
Product  ID  From  Sender 
File  Name 
System  ID 

IGES  Preprocessor  Version 
Number  of  Bits  for  Integer 
Single  Precision  Magnitude 
Single  Precision  Significance 
Double  Precision  Magnitude 
Double  Precision  Significance 
Product  ID  for  the  Receiver 
Model  Space  Scale 
Unit  Flag 
Units 

Maximum  Number  of  Lineweights 
Maximum  Line  Thickness 
Date  and  Time  of  Creation 
Minimum  Resolution 
Maximum  Coordinate  Value 
Name  of  Author 
Organization 
Version  Number 
Drafting  Standard  Code 

The  Product  ID  From  Sender,  field  3,  and  the  Product  ID  for  the  Receiver, 
field  12,  must  contain  the  Part  Number.  Field  3 and  Field  12  must  always  be 
given  values.  Field  3 and  Field  12  must  be  equal.  The  Part  Number  is 
defined  to  be  an  alpha-numeric  string  which  gives  the  number  that  uniquely 
identifies  the  part  contained  in  the  Drafting  APF  file. 

Examples : 10H0123456789  10H9999999999 

The  File  Name,  field  4,  must  contain  the  name  of  the  file  as  it  existed  on 
the  originating  system  using  the  appropriate  naming  conventions  of  the 
originating  system.  The  naming  conventions  of  the  originating  system  may  or 
may  not  include  disk  identifiers,  node  names,  directory  names,  etc. 
Therefore,  no  limit  is  placed  on  the  length  of  the  alpha-numeric  string  used 
to  carry  the  name  of  the  file.  This  field  must  always  be  given  a value. 

Examples : 43HDUA0 : [ CAD . DRAFTING . APF_FILES ] SPACER_ROD . DRW 
12HTESTFILE.DAT 
6HN002SA 

20HSAMPLE  XB PART 21  Al 

51H ' CADFILE . TEST . THIS . IS . A . FAIRLY . LONG . NAME (TESTPART) ' 

The  Global  section  fields  that  have  Field  Value  Requirements  consisting  of 
"As  Per  IGES,  non-null"  require  that  the  field  always  contain  a valid  value 
as  described  by  the  IGES  specification.  This  means  that  the  syntax  and 
semantics  defined  by  the  IGES  specification  must  be  used  to  prepare  the  required 


Field  Value  Requirement 


non 

non 

non 

non 

non 

non 

non 

see 


1H, 

1H; 

Part  Number, 

See  below 
As  Per  IGES , 

As  Per  IGES, 

As  Per  IGES , 

As  Per  IGES , 

As  Per  IGES , 

As  Per  IGES, 

As  Per  IGES , 

Part  Number, 

1.0 

1 or  2 

4HINCH  or  2HMM 
As  Per  IGES , non 
As  Per  IGES , 

As  Per  IGES , 

See  below 
See  below 
As  Per  IGES , 

As  Per  IGES , non 
As  Per  IGES , non 
See  below 


see  below 


non 

non 


■null 

■null 

■null 

•null 

■null 

■null 

■null 

below 


■null 

■null 

■null 


non- 


null 

null 

null 
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information  for  the  field.  This  restriction  pertains  to  fields  7-11,  16-18, 
and  21-23. 

The  Minimum  Resolution,  field  19,  must  contain  the  value  of  the  largest 
geometric  discontinuity  for  the  geometry  in  the  Drafting  APF  file,  i.e.,  the 
largest  "gap".  Because  of  the  dual  role  of  the  Drafting  APF,  the  Drafting 
APF  file  is  required  to  carry  both  the  product  data,  geometry,  tolerances, 
etc.,  and  the  graphics  necessary  to  produce  a drawing.  In  many  cases,  the 
product  data  geometry  in  the  Drafting  APF  file  must  be  used  by  manufacturing 
applications  to  produce  a product.  Manufacturing  applications  must  rely  on 
the  continuity  of  the  geometry,  and  this  reliance  requires  that  the  value  of 
Field  19  be  the  largest  geometric  discontinuity  in  the  Drafting  APF  file. 
With  this  value,  any  manufacturing  application  can  consider  coordinate 
locations  less  than  this  distance  apart  to  be  coincident.  This  field  value 
must  be  prepared  on  the  basis  of  each  APF  file's  contents  and  not  on  the 
basis  of  the  originating  system's  capability.  This  field  must  always  be 
given  a value . 

Examples:  0.00001  1.0E-5 

The  Maximum  Coordinate  Value,  field  20,  must  contain  the  value  of  the 
largest  X,  Y,  or  Z geometric  position  in  the  Drafting  APF  file.  This  field 
value  must  be  prepared  on  the  basis  of  each  APF  file's  contents  and  not  on 
the  basis  of  the  originating  system's  maximum  capability.  This  field  must 
always  be  given  a value. 

Examples:  1000.0  1.0E3 

The  Drafting  Standard  Code,  field  24,  must  contain  the  value  3,  because  the 
Feature  Control  Frame  example  is  based  on  the  American  National  Standards 
Institute's  Standard  for  Dimensioning  and  Tolerancing,  ANSI  Y14.5M,  1982. [6] 


II. 2 Directory  Entry  Section 


This  section  gives  the  Directory  Entry  section  restrictions  for  the  IGES 
entity  set.  The  restrictions  for  the  Directory  Entry  section  of  the  IGES 
entities  in  this  example  are  based  on  the  APIM  for  Feature  Control  Frames 
and  some  assumptions  about  the  remainder  of  the  APIM  for  the  Drafting  APF. 
These  assumptions  would  not  be  necessary  for  a complete  Drafting  APF  because 
the  complete  APIM  would  be  available  for  use  in  determining  the 
restrictions . 

The  restrictions  for  fields  1,  11,  and  15  were  determined  on  the  basis  of 
the  IGES  entity  set  that  was  selected  to  carry  the  information  for  Feature 
Control  Frames.  The  restrictions  for  fields  3,  4,  6,  7,  8,  9,  12,  and  13 
were  determined  on  the  basis  of  the  APIM  for  Feature  Control  Frames. 

The  restriction  for  field  5 was  determined  on  the  basis  of  an  assumption. 
The  assumption  is  that  the  complete  Drafting  APIM  will  require  a method  for 
separating  the  Drafting  information  into  specific  information  categories. 


-•a 
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The  APFS  will  use  the  Directory  Entry  section  level  field  to  carry  the  information 
category  number.  The  information  category  number  for  tolerance  information 
(Feature  Control  Frames)  is  250. 

The  restriction  for  fields  18  and  19  were  determined  on  the  basis  of  an 
assumption.  The  assumption  is  that  the  complete  Drafting  APIM  will  require 
a method  for  uniquely  identifying  each  entity  in  the  Drafting  APF.  The  APFS 
will  use  the  entity  label  and  subscript  fields  in  the  Directory  Entry 
section  to  carry  the  unique  identifier.  The  requirement  is  that  the 
combination  of  the  entity  label  value  and  the  subscript  value  provide  a unique 
identifier  for  each  entity  in  a Drafting  APF  file.  This  requirement  means 
that  a unique  entity  label  value  must  be  identified  for  each  IGES  entity 
type.  Also,  a unique  subscript  value  N must  be  supplied  for  each  entity  in 
the  APF  file,  where  N can  have  a value  from  1 to  the  number  entities  of  each 
type  in  the  APF  file.  The  entity  label  values  for  the  entities  in  this 
example  are: 


The  Directory  Entry  section  fields  that  have  Field  Value  Requirements 
consisting  of  "As  Per  IGES"  require  that  the  field  always  contain  a valid 
value  as  described  by  the  IGES  specification.  This  restriction  pertains  to 
Directory  Entry  section  fields  2,  10,  14,  and  20. 


228  General  Symbol 

212  General  Note 

106  Simple  Closed  Area 


"FCF_INF0" 
"FCF_TEXT" 
" FCF_B0X" 
" FCF  SEP" 


110  Line 
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II. 2.1  General  Symbol  Entity 


Directory  Entry  Section  Field 


Field  Value  Requirement 


Entity  Type 

Parameter  Data  Pointer 

Structure 

Line  Font  Pattern 

Level 

View 

Transformation  Matrix 
Label  Display  Associativity 
Status  Number: 

Blank  Status 

Subordinate  Entity  Switch 
Entity  Use  Flag 
Hierarchy 

Section  Code  and  Sequence  Number 
Entity  Type 
Line  Weight  Number 
Color  Number 

Parameter  Line  Count  Number 

Form  Number 

Reserved  Field 

Reserved  Field 

Entity  Label 

Entity  Subscript  Number 

Section  Code  and  Sequence  Number 


228 

As  Per  ICES 
0 
1 

250 

0 

0 

0 


0 

0 

1 

1 

As  Per  IGES 
228 
0 
0 


As  Per  IGES 

0 

Blank 

Blank 

FCF_INF0 

N 

As  Per  IGES 
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II. 2. 2 General  Note  Entity 


Directory  Entry  Section  Field 


Field  Value  Requirement 


Entity  Type 

Parameter  Data  Pointer 

Structure 

Line  Font  Pattern 

Level 

View 

Transformation  Matrix 
Label  Display  Associativity 
Status  Number: 

Blank  Status 

Subordinate  Entity  Switch 
Entity  Use  Flag 
Hierarchy 

Section  Code  and  Sequence  Number 
Entity  Type 
Line  Weight  Number 
Color  Number 

Parameter  Line  Count  Number 

Form  Number 

Reserved  Field 

Reserved  Field 

Entity  Label 

Entity  Subscript  Number 

Section  Code  and  Sequence  Number 


212 

As  Per  IGES 
0 
1 

250 

0 

0 

0 


0 

1 

1 

1 

As  Per  IGES 
212 
0 
0 


As  Per  IGES 
0 

Blank 

Blank 

FCF_TEXT 

N 

As  Per  IGES 


B - 19 


II. 2. 3 Simple  Closed  Area  Entity 


Directory  Entry  Section  Field 


Field  Value  Requirement 


Entity  Type 

Parameter  Data  Pointer 

Structure 

Line  Font  Pattern 

Level 

View 

Transformation  Matrix 
Label  Display  Associativity 
Status  Number: 

Blank  Status 

Subordinate  Entity  Switch 
Entity  Use  Flag 
Hierarchy 

Section  Code  and  Sequence  Number 
Entity  Type 
Line  Weight  Number 
Color  Number 

Parameter  Line  Count  Number 

Form  Number 

Reserved  Field 

Reserved  Field 

Entity  Label 

Entity  Subscript  Number 

Section  Code  and  Sequence  Number 


106 

As  Per  IGES 
0 
1 

250 

0 

0 

0 


0 

1 

1 

1 

As  Per  IGES 
106 
0 
0 

As  Per  IGES 
63 

Blank 

Blank 

FCF_B0X 

N 

As  Per  IGES 
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II. 2.4  Line  Entity 


Directory  Entry  Section  Field 


Field  Value  Requirement 


Entity  Type 

Parameter  Data  Pointer 

Structure 

Line  Font  Pattern 

Level 

View 

Transformation  Matrix 
Label  Display  Associativity 
Status  Number: 

Blank  Status 

Subordinate  Entity  Switch 
Entity  Use  Flag 
Hierarchy 

Section  Code  and  Sequence  Number 
Entity  Type 
Line  Weight  Number 
Color  Number 

Parameter  Line  Count  Number 

Form  Number 

Reserved  Field 

Reserved  Field 

Entity  Label 

Entity  Subscript  Number 

Section  Code  and  Sequence  Number 


110 

As  Per  IGES 
0 
1 

250 

0 

0 

0 


0 

1 

1 

1 

As  Per  IGES 
110 
0 
0 


As  Per  IGES 
0 

Blank 

Blank 


FCF_SEP 

N 


As  Per  IGES 
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II. 3 Parameter  Data  Section 


This  section  outlines  the  Parameter  Data  section  restrictions  for  the  IGES 
entity  set.  The  restrictions  given  in  this  section  are  intended  to  reduce 
the  possible  Parameter  Data  section  field  values  to  only  what  is  necessary 
for  the  Feature  Control  Frames  APF.  The  usage  guide  assigns  a specific 
meaning  to  each  Parameter  Data  section  field  for  carrying  Feature  Control  Frame 
information.  The  usage  guide  is  given  in  a later  section. 

The  restrictions  for  the  Parameter  Data  section  of  the  IGES  entitles  in  this 
example  will  be  based  either  explicitly  or  implicitly  on  the  APIM  for 
Feature  Control  Frames  and  an  assumption  about  the  remainder  of  the  APIM  for 
the  Drafting  APF. 

The  APIM  for  Feature  Control  Frames  does  not  require  the  use  of  the  IGES 
associativity/general  note  backpointers  or  property  backpointers.  The 
assumption  is  that  no  IGES  associativity  or  general  note  backpointers  will 
be  required  by  the  remainder  of  the  APIM  for  the  Drafting  APF.  Also,  the 
assumption  is  that  no  IGES  property  backpointers  will  be  required  by  the 
remainder  of  the  APIM  for  the  Drafting  APF.  These  assumptions  would  not  be 
necessary  for  a complete  Drafting  APF  because  the  complete  APIM  would  be 
available  for  use  in  determining  the  restrictions. 
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II. 3.1  General  Symbol  Entity 


Parameter  Data  Section  Field 

Field  Value  Requirement 

ENTITY  TYPE  NUMBER 

228 

DENOTE 

Pointer  to  associated  general  note 

N 

Number  of  pointers  to  geometry 

GPNT1 

Pointer  to  defining  geometry 

GPNTN 

L 

0;  No  pointers  to  Leader  entities 

NA 

0;  No  pointers  to  Associativity  or  General 
Note  entities 

NP 

0;  No  pointers  to  Property  entities 
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II. 3. 2 General  Note  Entity 


Parameter  Data  Section  Field 

Field  Value  Requirement 

ENTITY  TYPE  NUMBER 

212 

NS 

Number  of  text  strings  in  general  note 

NCI 

Number  of  characters  in  first  text 
string;  must  be  greater  than  0 

WT1 

Box  width 

HT1 

Box  height 

FC1 

Font  Characteristic;  must  be  equal  to 
1,  1001 

SL1 

Slant  angle;  must  be  equal  to  1.5708 

Al 

Rotation  angle  in  radians;  must  be 
equal  to  0.0 

Ml 

Mirror  flag;  must  be  equal  to  0 

VH1 

Rotate  internal  text  flag;  must  be 
equal  to  0 

XS1 

First  text  start  point  X 

YS1 

First  text  start  point  Y 

ZS1 

Z depth;  must  be  equal  to  0.0 

TEXT1 

First  text  string 

NC2 

Number  of  characters  in  second  text  string 

TEXT  2 

Second  text  string 

NCNS 

Number  of  characters  in  last  text  string 

TEXTNS 

Last  text  string 

B - 24 


NA 


0;  No  pointers  to  Associativity  or  General 
Note  entities 


NP  0 ; No  pointers  to  Property  entities 

The  set  of  General  Note  Parameter  Data  section  fields  may  be  repeated  as 
many  times  as  necessary  to  define  all  of  the  text  strings. 
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II. 3. 3 Simple  Closed  Area  Entity 


Parameter  Data  Section  Field 

Field  Value  Requirement 

ENTITY  TYPE  NUMBER 

106 

IP 

Interpretation  Flag;  must  be  equal  to 
1 

N1 

Number  of  n- tuples;  must  be  equal  to  4 

ZT 

Common  Z displacement;  must  be  equal 
to  0.0 

XI 

First  data  point  abscissa 

Y1 

First  data  point  ordinate 

X4 

Fourth  data  point  abscissa 

Y4 

Fourth  data  point  ordinate 

NA 

0;  No  pointers  to  Associativity  or  General 
Note  entities 

NP 

0;  No  pointers  to  Property  entities 
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II. 3.4  Line  Entity 


Parameter  Data  Section  Field. 

ENTITY  TYPE  NUMBER 

XI 

Y1 

Z1 

X2 

Y2 

Z2 

NA 

NP 


Field  Value  Requirement 
110 

X coordinate  of  start  point 

Y coordinate  of  start  point 

Z coordinate  of  start  point;  must  be  equal 
to  0,0 

X coordinate  of  terminate  point 

Y coordinate  of  terminate  point 

Z coordinate  of  terminate  point;  must 
be  equal  to  0,0 

0;  No  pointers  to  Associativity  or  General 
Note  entities 

0;  No  pointers  to  Property  entities 
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III.  Usage  Guide  for  the  IGES  Entities 


This  section  specifies  the  use  of  the  IGES  entities  in  carrying  Drafting 
Feature  Control  Frame  information  as  defined  by  the  APIM.  The  use  of  the 
IGES  entities  was  determined  by  referring  to  the  Feature  Control  Frames 
Application  Reference  Model  (ARM) , two  Application  Implementation  Models 
(AIM),  and  the  Application  IGES  Implementation  Model  (AIIM)  from  Appendix  B.l. 

The  Feature  Control  Frames  ARM  represents  the  Drafting  information  that  is 
required  for  a Feature  Control  Frame.  This  ARM  is  a part  of  the  complete 
Drafting  APIM.  The  ARM  is  a model  of  Feature  Control  Frame  information  that 
can  be  validated  by  a Drafting  application  area  expert. 

Appendix  B.l  contains  two  AIMs , the  initial  AIM  and  the  final  AIM.  The 
initial  AIM  is  the  AIM  that  was  developed  on  the  basis  of  the  ARM  and  shows 
the  Drafting  information  for  Feature  Control  Frames  that  must  be 
"identifiable"  in  the  IGES  entities  in  the  Drafting  APF.  The  meaning  of 
"identifiable"  in  this  context  is  that  it  must  be  possible  to  have  a 
reversible  mapping  of  Feature  Control  Frame  information  from  the  ARM  into 
the  IGES  entities  in  the  APF.  The  initial  AIM  provides  a description  of  the 
way  that  the  Feature  Control  Frame  information  must  be  structured  to  allow 
an  explicit  reversible  mapping. 

Because  of  the  implementation  decisions  and  trade-offs  as  discussed  in 
Appendix  B.l,  the  final  AIM  provides  a less  explicit  "identification"  of 
each  item  of  Feature  Control  Frame  information  in  the  APF  entities.  In 
reality,  this  means  that  it  will  not  be  possible  to  have  an  explicit 
reversible  mapping  of  Feature  Control  Frame  information.  It  is  important  to 
realize  that  it  will  be  possible  to  reverse  the  mapping,  but  the  reverse 
mapping  will  require  "parsing"  the  embedded  information. 

Appendix  B.l  contains  the  AIIM  that  is  based  on  the  initial  and  final  AIMs. 
The  final  AIM  and  the  resulting  AIIM  are  based  on  implementation  decisions 
and  trade-offs  and  can  be  implemented  by  using  existing  IGES  entities.  The 
AIIM  of  Appendix  B.l  shows  the  Drafting  information  for  Feature  Control 
Frames  after  it  has  been  abstracted  to  an  appropriate  level  for  use  in 
selecting  the  necessary  IGES  entities  to  carry  the  information.  This  AIIM  was 
used  to  select  the  required  IGES  entity  set  for  this  APFS . 

The  final  AIM  and  the  accompanying  AIIM  from  Appendix  B.l  are  the  models 
that  were  used  to  prepare  this  APFS  for  Feature  Control  Frames . In 
addition,  the  final  AIM  and  AIIM  models  illustrate  the  required  structure 
for  the  Feature  Control  Frame  information  as  it  must  be  carried  in  the  IGES 
entities  in  the  APF. 

Section  II  of  this  Appendix,  the  Global,  Directory  Entry,  and  Parameter  Data 
section  restrictions,  described  the  field  value  limitations.  This  section 
gives  a detailed  description  of  how  the  information  from  the  information 
models  must  be  embedded  into  each  IGES  entity  for  the  Feature  Control 
Frames.  This  section  will  define  the  meaning  of  the  necessary  fields  in  the 
Parameter  Data  section  of  each  entity  for  carrying  Feature  Control  Frames 
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information.  Any  fields  that  do  not  require  a specific  meaning  as  per  the 
APIM  will  retain  the  description  as  given  in  Section  II.  Based  on  the 
information  models,  the  use  of  each  IGES  entity  can  be  given  in  summary 
statements  as  follows. 

In  terms  of  the  final  AIM,  the  General  Note  entity  will  be  used  to  carry  the 
Geometric  Characteristic,  the  Tolerance  Specification,  the  Maximum  Tolerance 
Specification,  and  the  Datum  Reference.  The  Tolerance  Specification 
contains  the  Tolerance  Cylindrical  Form,  the  Tolerance  Value,  the  Tolerance 
Material  Condition,  the  Tolerance  Unit  Length,  and  the  Tolerance  Unit 
Width.  The  Maximum  Tolerance  Specification  contains  the  Tolerance 
Cylindrical  Form  and  the  Maximum  Tolerance  Value.  The  Datum  Reference 
contains  the  Datum  Identifier  and  the  Datum  Material  Condition. 

In  terms  of  the  final  AIM,  the  Simple  Closed  Area  entity  will  be  used  to 
carry  the  Frame  Box  that  is  defined  by  four  coordinate  pairs.  The  Line 
entity  will  be  used  to  carry  the  Frame  Box  Divider  that  is  defined  by  two 
coordinate  pairs.  The  General  Symbol  entity  will  be  used  to  carry  the 
associativity  of  the  General  Note,  the  Simple  Closed  Area,  and  the  Line  entities. 


III.l  General  Symbol  Entity 


The  Directory  Entry  section  field  value  requirements  for  the  General  Symbol 
entity  are  given  in  II. 2.1.  Therefore,  this  section  will  not  discuss  the 
Directory  Entry  section  for  the  General  Symbol  entity. 

The  Parameter  Data  section  field  value  requirements  for  the  General  Symbol 
entity  are  outlined  in  II.  3.1.  This  section  will  specify  the  use  of  the 
Parameter  Data  section  fields  for  the  General  Symbol  entity  in  terms  of  the 
final  AIM  and  IGES. 

The  General  Symbol  Entity  will  be  used  to  carry  the  associativity  for  the 
General  Note,  Simple  Closed  Area,  and  Line  entities  and  to  group  these 
entities  together  into  a Feature  Control  Frame  entity.  In  terms  of  IGES, 
this  means  that  the  General  Symbol  entity  will  be  used  to  carry  the  pointers 
to  the  General  Note,  Simple  Closed  Area,  and  Line  entities.  The  order  and 
meaning  of  the  Parameter  Data  section  fields  for  the  General  Symbol  entity 
are  given  below.  The  use  of  each  entity  that  is  pointed  to  by  the  General 
Symbol  entity  will  be  described  in  subsequent  sections. 

The  General  Symbol  entity  can  carry  only  one  pointer  to  a General  Note 
entity.  The  General  Symbol  can  carry  multiple  pointers  to  geometry 
entities.  These  geometry  entity  pointers  will  point  to  Simple  Closed  Area 
and  Line  entities.  There  must  be  one  or  more  pointers  to  a Simple  Closed 
Area  entity  and  one  or  more  pointers  to  Line  entities.  The  pointers  to  the 
Simple  Closed  Area  entity  must  be  placed  in  the  list  before  the  pointers  to 
the  Line  entities.  The  General  Symbol  entity  must  contain  no  pointers  to 
Leader  entities. 
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Parameter  Data  Section  Field 


Field  Value  Requirement 
ENTITY  TYPE  NUMBER  228 


DENOTE 


N 


GPNT1 


Pointer  to  the  general  note  entity  that 
contains  the  Geometric  Characteristic, 
the  Tolerance  Specification,  the  Maximum 
Tolerance  Value  Specification,  and  the 
Datum  Reference  information 

Total  number  of  pointers  to  Simple  Closed 
Area  and  Line  entities  defining  Frame 
Boxes  and  Frame  Box  Dividers;  there 
will  be  one  or  more  pointers  to  Simple 
Closed  Area  entities  and  one  or  more 
pointers  to  Line  entities 

Pointer  to  a Simple  Closed  Area  or  Line 
entity 


GPNTN 

L 0;  No  pointers  to  Leader  entities 

NA  0;  No  pointers  to  Associativity  or  General 

Note  entities 

NP  0 ; No  pointers  to  Property  entities 

III. 2 General  Note  Entity 


The  Directory  Entry  section  field  value  requirements  for  the  General  Note 
entity  are  given  in  II.  2. 2.  Therefore,  this  section  will  not  discuss  the 
Directory  Entry  section  for  the  General  Note  entity. 

The  Parameter  Data  section  field  value  requirements  for  the  General  Note 
entity  are  outlined  in  II.  3. 2.  This  section  will  specify  the  use  of  the 
Parameter  Data  section  fields  for  the  General  Note  entity  in  terms  of  the 
final  AIM  and  IGES . 

From  the  final  AIM,  the  Feature  Control  Frame  contains  the  Geometric 
Characteristic,  the  Tolerance  Specification,  the  Maximum  Tolerance  Value 
Specification,  and  the  Datum  Reference.  The  Geometric  Characteristic  will  be 
represented  by  a Geometric  Characteristic  Symbol. 

The  Tolerance  Specification  is  identified  by  a Tolerance  Specification 
Identifier.  The  Tolerance  Specification  will  contain  the  Tolerance 
Cylindrical  Form,  the  Tolerance  Value,  the  Tolerance  Material  Condition,  the 


B - 30 


Tolerance  Unit  Length,  and  the  Tolerance  Unit  Width.  The  Tolerance 
Cylindrical  form  will  be  represented  by  a Diameter  Symbol.  The  Tolerance 
Value  will  be  represented  by  a Tolerance  Value  String.  The  Tolerance 
Material  Condition  will  be  represented  by  a Material  Condition  Symbol.  The 
Tolerance  Unit  Length  will  be  represented  by  a Tolerance  Unit  Length  String. 
The  Tolerance  Unit  Width  will  be  represented  by  a Tolerance  Unit  Width  String. 

The  Maximum  Tolerance  Value  Specification  is  identified  by  a Maximum 
Tolerance  Specification  Identifier.  The  Maximum  Tolerance  Value 
Specification  contains  a Tolerance  Cylindrical  Form  represented  by  a 
Diameter  Symbol.  The  Maximum  Tolerance  Value  Specification  contains  a 
Maximum  Tolerance  Value  that  is  represented  by  Maximum  Tolerance  Value  String. 

The  Datum  Reference  is  identified  by  a Datum  Reference  Identifier.  The 
Datum  Reference  contains  a Datum  Identifier  that  is  represented  by  a Datum 
Identifier  String.  The  Datum  Reference  contains  a Datum  Material  Condition 
that  is  represented  by  a Datum  Material  Condition  Symbol. 

Only  one  General  Note  entity  can  be  included  in  a General  Symbol  entity. 
However,  the  single  General  Note  entity  can  have  an  unlimited  number  of 
strings.  The  Feature  Control  Frame  will  have  two  or  more  "compartments" 
that  are  represented  by  the  Frame  Box  and  the  Frame  Box  Dividers.  Each  of 
the  compartments  will  contain  either  a Geometric  Characteristic,  a Tolerance 
Specification,  a Maximum  Tolerance  Value  Specification,  or  a Datum 
Reference.  Therefore,  this  APFS  will  allocate  one  string  in  the  General 
Note  entity  to  carry  the  contents  of  each  compartment  in  the  Feature  Control 
Frame.  This  means  that  the  contents  of  each  compartment  must  be  contained 
In  a General  Note  string  having  a font  characteristic  such  that  the  contents 
can  be  correctly  represented.  The  order  of  the  text  and  symbol  strings  in  the 
General  Note  entity  must  be  from  left  to  right  as  per  the  order  of  the 
compartments  in  the  Feature  Control  Frame. 
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Parameter  Data  Section  Field 

Field  Value  Requirement 

ENTITY  TYPE  NUMBER 

212 

NS 

Number  of  compartments  in  the  Feature 
Control  Frame;  must  be  >=  2 

NCI 

Number  of  symbols  and/or  text 
characters  in  the  first  string;  must 
be  > 0 

WT1 

Symbol  and/or  text  character  string 
width;  must  be  > 0.0 

HT1 

Symbol  and/or  text  character  string 
height;  must  be  > 0.0 

FC1 

Symbol  and/or  text  character  string 
font  characteristic;  must  be  equal  to 
1,  1001 

SL1 

Symbol  and/or  text  character  slant 
angle;  must  be  equal  to  1.5708 

Al 

Rotation  angle  in  radians;  must  be 
equal  to  0.0 

Ml 

Mirror  flag;  must  be  equal  to  0 

VH1 

Rotate  internal  text  flag;  must  be 
equal  to  0 

XS1 

First  symbol  and/or  text  character 
string  start  point  X 

YS1 

First  symbol  and/or  text  character 
string  start  point  Y 

ZS1 

Z depth;  must  be  equal  to  0.0 

TEXT1 

First  symbol  and/or  text  character  string 

NC2 

Number  of  symbols  and/or  text 
characters  in  the  second  string;  must 
be  > 0 

TEXT  2 

Second  symbol  and/or  text  character  string 
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NCNS 


Number  of  symbols  and/or  text 
characters  in  the  last  string;  must  be 
> 0 


TEXTNS  Last  symbol  and/or  text  character  string 

NA  0;  No  pointers  to  Associativity  or  General 

Note  entities 

NP  0 ; No  pointers  to  Property  entities 


There  is  no  limit  on  the  number  of  symbol  and/or  text  character  strings  that 
may  be  included  in  the  General  Note  entity.  The  number  of  strings  in  the 
General  Note  entity  must  be  equal  to  the  number  of  compartments  in  the 
Feature  Control  Frame. 
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III. 3 Simple  Closed  Area  Entity 


The  Directory  Entry  section  field  value  requirements  for  the  Simple  Closed 
Area  entity  are  given  in  II. 2. 3.  Therefore,  this  section  will  not  discuss 
the  Directory  Entry  section  for  the  Simple  Closed  Area  entity. 

The  Parameter  Data  section  field  value  requirements  for  the  Simple  Closed 
Area  entity  are  outlined  in  II.  3. 3.  This  section  will  specify  the  use  of 
the  Parameter  Data  section  fields  for  the  Simple  Closed  Area  entity  in  terms 
of  the  final  AIM  and  IGES . 

From  the  final  AIM,  the  Feature  Control  Frame  is  represented  by  a Frame  Box. 
The  Frame  Box  is  defined  by  four  coordinate  pairs  that  each  consist  of  an  X 
Value  and  a Y Value.  The  Frame  Box  is  identified  by  a Frame  Box  Identifier. 

The  Simple  Closed  Area  entity  will  be  used  to  carry  the  Frame  Box  for  the 
Feature  Control  Frame.  Visually,  the  Frame  Box  is  made  up  of  four  vertices 
and  four  curve  segments.  The  Simple  Closed  Area  entity  will  contain  four 
coordinate  pairs  of  data  points  that  represent  the  vertices  of  the  box  and 
the  four  curve  segments  that  make  up  the  box. 
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Parameter  Data  Section  Field 


Field  Value  Requirement 


ENTITY 

TYPE  NUMBER  106 

IP 

Interpretation  Flag;  must  be  equal  to 
1 

N1 

Number  of  Coordinate  Pairs  for  the  Frame 
Box;  must  be  equal  to  4 

ZT 

Common  Z displacement;  must  be  equal 
to  0.0 

XI 

X Value  for  the  first  corner  of  the 
Frame  Box 

Y1 

Y Value  for  the  first  corner  of  the 
Frame  Box 

X2 

X Value  for  the  second  comer  of  the  Frame 
Box 

Y2 

Y Value  for  the  second  comer  of  the  Frame 
Box 

X3 

X Value  for  the  third  corner  of  the 
Frame  Box 

Y3 

Y Value  for  the  third  corner  of  the 
Frame  Box 

X4 

X Value  for  the  fourth  comer  of  the  Frame 
Box 

Y4 

Y Value  for  the  fourth  comer  of  the  Frame 
Box 

NA 

0;  No  pointers  to  Associativity  or  General 
Note  entities 

NP 

0;  No  pointers  to  Property  entities 
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III. 4 Line  Entity 


The  Directory  Entry  section  field  value  requirements  for  the  Line  entity  are 
given  in  II. 2. 4.  Therefore,  this  section  will  not  discuss  the  Directory 
Entry  section  for  the  Line  entity. 

The  Parameter  Data  section  field  value  requirements  for  the  Line  entity  are 
outlined  in  II. 3.4.  This  section  will  specify  the  use  of  the  Parameter  Data 
section  fields  for  the  Line  entity  in  terms  of  the  final  AIM  and  IGES . 

From  the  final  AIM,  the  Feature  Control  Frame  is  compartmentalized  by  the 
Frame  Box  Divider  that  is  defined  by  two  coordinate  pairs  that  each  consist 
of  an  X Value  and  a Y Value.  The  Frame  Box  Divider  is  identified  by  a Frame 
Box  Divider  Identifier. 

The  Line  entity  will  be  used  to  carry  the  Frame  Box  Dividers  for  the 
compartments  of  the  Feature  Control  Frame.  There  must  be  two  or  more 
compartments  in  the  Feature  Control  Frame.  The  number  of  Frame  Box  Dividers 
must  be  one  less  than  the  number  of  compartments  in  the  Feature  Control 
Frame.  Each  Frame  Box  Divider  must  consist  of  two  endpoints  that  define  one 
curve  segment. 


Parameter  Data  Section  Field  Field  Value  Requirement 

ENTITY  TYPE  NUMBER  110 


XI 

X Value  for  the  start  point  of  the  Frame 
Box  Divider 

Y1 

Y Value  for  the  start  point  of  the  Frame 
Box  Divider 

Z1 

Z coordinate  of  start  point;  must  be  equal 
to  0.0 

X2 

X Value  for  the  terminate  point  of  the 
Frame  Box  Divider 

Y2 

Y Value  for  the  terminate  point  of  the 
Frame  Box  Divider 

Z2 

Z coordinate  of  terminate  point;  must 
be  equal  to  0.0 

NA 

0;  No  pointers  to  Associativity  or  General 
Note  entities 

NP 

0;  No  pointers  to  Property  entities 
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Appendix  B . 3 


FEATURE  CONTROL  FRAMES  - APPLICATION  PROTOCOL  FORMAT  TEST  CASES 


This  Appendix  describes  the  set  of  test  cases  for  the  Feature  Control  Frame 
example.  The  test  cases  for  this  example  were  prepared  as  per  the  technical 
content  requirements  given  in  Section  3.1. 

The  set  includes  ten  test  cases,  and  the  test  cases  are  based  on  the  Feature 
Control  Frames  illustrated  in  Figure  B5 . These  test  cases  were  taken  from 
examples  given  in  the  ANSI  Standard  for  Dimensioning  and  Tolerancing,  ANSI 
Y14.5M,  1982. [6]  In  Figure  B5 , the  Feature  Control  Frames  are  identified  by 
FCF#1,  FCF#2 , etc.  These  names  identify  the  test  cases  and  appear  in  the 
test  case  listings. 

Test  case  numbers  1-6,  identified  as  FCF#1-FCF#6  in  Figure  B5 , contain 
various  mixes  of  Geometric  Characteristic  Symbols,  Tolerance  Cylindrical 
Form-Diameter  Symbols,  Tolerance  Value  Strings,  Material  Condition  Symbols, 
Datum  Identifiers,  and  Material  Condition  Symbols.  Each  of  test  cases  1-6 
contain  a Frame  Box,  and  one  or  more  Frame  Box  Dividers. 

Test  case  number  7 contains  many  of  the  same  information  items  as  test  cases 
1-6,  but  also  contains  a Tolerance  Unit  Length  String.  Test  case  number  8 
contains  similar  information  items  as  the  other  test  cases,  but  it  also 
contains  a Tolerance  Unit  Width  String.  Test  case  number  9 contains  an 
additional  information  item,  the  Maximum  Tolerance  Value  String.  Finally, 
test  case  number  10  is  known  as  a Composite  Feature  Control  Frame. [6]  As 
shown  in  Figure  B5 , the  Composite  Feature  Control  Frame  is  made  up  of  a 
"double"  Frame  Box  with  one  Geometric  Characteristic  Symbol  and  two  individual 
Tolerance  Specifications. 

The  test  cases  are  handmade  test  cases  and  were  prepared  as  per  the  Application 
Protocol  Format  Specification  given  in  Appendix  B.2  and  the  IGES  Test  Case 
Development  Committee's  Guide  to  Developing  Entity  Test  Cases. [7] 
Currently,  test  cases  for  application  protocols  are  not  required  to  conform 
to  the  specifications  of  the  test  case  development  guide.  The  standard  file 
documentation  header  is  used  as  an  example  of  one  file  documentation  method. 

A listing  of  the  AP  format  files  for  these  ten  test  cases  is  given  below. 
These  ten  test  cases  have  been  thoroughly  checked  for  correctness  using  both 
manual  methods  and  software  methods.  In  addition,  each  test  case  has  been 
read  with  an  IGES  postprocessor  into  a CAD  system,  plotted,  and  visually 
verified  to  correctly  represent  each  of  the  Feature  Control  Frames 
illustrated  in  Figure  B5. 
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FEATURE  CONTROL  FRAME  TEST  CASES 
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Figure  B5  (Cont.) 


s 

F FCFTC01  S 

DAT  S 

S 

V IGES  3.0  s 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 IS 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #1.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb~1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000011111 , 11HFCFTC01 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000011111, 1.0,1,4HINCH, 8,0. 08, 13H880224. 104500, 0.0001, 8. 7500,  G 

1.4HR . J.  HARRISON,  24HD0E/Sandia  National  Labs,  4,0;  G 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

1 

2 

3 
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228 

1 

0 

1 

250 

0 

0 000000101D 

1 

228 

0 

0 

1 

0 

FCF  INFO  ID 

2 

212 

2 

0 

1 

250 

0 

0 000010101D 

3 

212 

0 

0 

3 

0 

FCF  TEXT  ID 

4 

106 

5 

0 

1 

250 

0 

0 000010101D 

5 

106 

0 

0 

2 

63 

FCF  BOX  ID 

6 

110 

7 

0 

1 

250 

0 

0 000010101D 

7 

110 

0 

0 

1 

0 

FCF  SEP  ID 

8 

228 .3.2. 5. 7. 0. 0.0; 

212.2.1.0. 3332.0. 5000 . 1001 .1.5708.0. 0000 .0.0.5.2500.5.1500, 

0. 0000, lHc, 4, 2. 0833, 0.5000, 1,1. 5708, 0.0000, 0,0, 6. 5000, 5. 1500, 
0 . 0000 , 4H0 .08,0,0; 

106.1.4.0.  0000 . 5 . 0000 . 5 . 8000 .8.7500.5. 8000 .8.7500.5. 0000 , 
0.0000,5.0000,0,0; 

110.6. 2500 . 5 . 8000 . 0 .  0000 .6.2500.5. 0000 . 0 . 0000 .0.0; 

S 48G  3D  8P  7 


IP 

3P 

3P 

3P 

5P 

5P 

7P 

T 


1 

2 

3 

4 

5 

6 
7 
1 
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s 

F FCFTC02  S 

DAT  S 

S 

V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 IS 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #2.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000022222 , 11HFCFTC02 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000022222 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 134000 , 0 . 0001 , 10 . 5000 , G 

14HR . J.  HARRISON, 24HDOE/Sandia  National  Labs, 4,0;  G 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

1 
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3 


B - 42 


228 

1 

0 

1 

250 

0 

0 000000101D 

1 

228 

0 

0 

1 

0 

FCF  INFO  ID 

2 

212 

2 

0 

1 

250 

0 

0 000010101D 

3 

212 

0 

0 

3 

0 

FCF  TEXT  ID 

4 

106 

5 

0 

1 

250 

0 

0 000010101D 

5 

106 

0 

0 

2 

63 

FCF  BOX  ID 

6 

110 

7 

0 

1 

250 

0 

0 000010101D 

7 

110 

0 

0 

1 

0 

FCF  SEP  ID 

8 

228 .3. 2. 5. 7. 0. 0.0; 

212.2.1.1. 0000 .  0 . 5000 . 1001 . 1 . 5708 . 0 . 0000 .0.0.5.2500.5. 1500  , 
0 . 0000 , 1H- , 6 , 3 . 5000 , 0 . 5000 , 1001 , 1 . 5708 , 0 . 0000 ,0,0,6. 7500 , 

5.1500.0.  0000 . 6Hn0 . 14m , 0 , 0 ; 

106.1.4.0.  0000 . 5 . 0000 .5.8000.10.5000.5.8000.10.5000.5. 0000 , 

5.0000. 5.0000.0.0; 

110.6. 5000 .5.8000.0.  0000 . 6 . 5000 . 5 . 0000 . 0 . 0000 .0.0; 

S 48G  3D  8P  7 


IP 

3P 

3P 

3P 

5P 

5P 

7P 

T 


1 

2 

3 

4 

5 

6 
7 
1 


3 


43 


s 

F FCFTC03  S 

DAT  S 

S 

V IGES  3 . 0 S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 1 S 

106  63  IS 

110  0 2 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #3 . S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H, , 1H ; , 10H0000033333 , 11HFCFTC03 . DAT , 8HHANDMADE , 3H1 .0,32,38,6,38,15,  G 

10H0000033333 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 140500 , 0 . 0001 , 11 . 5000 , G 

14HR . J.  HARRISON, 24HDOE/Sandia  National  Labs, 4,0;  G 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

1 

2 

3 
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228  1 

0 1 

250 

0 

0 

000000101D 

1 

228  0 

0 1 

0 

FCF 

INFO 

ID 

2 

212  2 

0 1 

250 

0 

0 

000010101D 

3 

212  0 

0 4 

0 

FCF 

TEXT 

ID 

4 

106  6 

0 1 

250 

0 

0 

000010101D 

5 

106  0 

0 2 

63 

FCF 

BOX 

ID 

6 

110  8 

0 1 

250 

0 

0 

000010101D 

7 

110  0 

0 1 

0 

FCF 

SEP 

ID 

8 

110  9 

0 1 

250 

0 

0 

000010101D 

9 

110  0 

0 1 

0 

FCF 

_SEP 

2D 

10 

228,3,3,5,7,9,0,0 

,0; 

IP 

1 

212,3,1,0.5547,0. 

5000,1001,1.5708,0 

0000,0,0,5. 

2500,5 

1500, 

3P 

2 

5 . 0000 , 1H1 , 6 , 3 . 5000 , 0 . 5000 ,1001,1.5708,0. 0000 , 0 

,0,6.7500, 

3P 

3 

5 . 1500 , 0 . 0000 , 6Hn0 . 05m, 1,0. 5000 , 0 . 5000 ,1,1.5708 

,0.0000,0,0, 

3P 

4 

L0. 7500, 5. 1500,0. 

0000, 1HC, 0,0; 

3P 

5 

106,1,4,0.0000,5. 

0000 , 5 . 8000 , 11 . 5000 , 5 . 8000 , 11 . 

5000,5 

0000, 

5P 

6 

5.0000,5.0000,0,0 

5P 

7 

110,6.5000,5.8000 

, 0 . 0000 , 6 . 5000 , 5 . 0000 , 0 . 0000 ,0,0; 

7P 

8 

110 , 10 . 5000 , 5 . 8000 , 0 . 0000 ,10.5000,5 

0000,0.0000 

,0,0; 

9P 

9 

3 48G  3D 

10P  9 

T 

1 

B - 45 


s 

F FCFTC04  S 

DAT  S 

S 

V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 2 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #4.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000044444 , 11HFCFTC04 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000044444 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 144500 , 0 . 0001 ,10.7500,  G 

14HR . J.  HARRISON, 24HD0E/Sandia  National  Labs, 4,0;  G 

228  1 0 1 250  0 0 000000101D 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

1 

2 

3 

1 


B - 46 


228 

0 

0 

1 

0 

FCF  INFO  ID 

212 

2 

0 

1 

250 

0 

0 000010101D 

212 

0 

0 

4 

0 

FCF  TEXT  ID 

106  • 

6 

0 

1 

250 

0 

0 000010101D 

106 

0 

0 

2 

63 

FCF  BOX  ID 

110 

8 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  ID 

110 

9 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  2D 

228.3.3.5.7.9.0. 0.0;  IP 

212.3.1.0. 5547.0.5000.1001.1.5708.0.0000.0.0.5.2500.5.1500,  3P 


0 . 0000 , lHh , 4 , 2 . 0000 , 0 . 5000 ,1,1.5708,0. 0000 ,0,0,6. 5000 , 3P 

5 . 1500 . 0 .  0000 . 4H0 . 05 , 3 , 1 . 5000 , 0 . 5000 ,1,1.5708,0. 0000 ,0,0,  3P 

9 . 0000 .  5 . 1500 . 0 . 0000 . 3HA-B , 0,0;  3P 

106.1.4.0.  0000 . 5 . 0000 . 5 . 8000 .10.7500.5. 8000 .10.7500.5. 0000 , 5P 

5.0000. 5.0000.0.0;  5P 

110.6. 2500 . 5 . 8000 . 0 .  0000 . 6 . 2500 . 5 . 0000 . 0 . 0000 .0.0;  7P 

110.8. 7500 . 5 . 8000 . 0 .  0000 .8.7500.5. 0000 . 0 . 0000 .0.0;  9P 

S 48G  3D  10P  9 T 


s 

F FCFTC05  S 

DAT  S 

S 

V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 3 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #5.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000055555 , 11HFCFTC05 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000055555,1.0,1,4HINCH,8,0.08,13H880224. 150500, 0.0001, 12. 7 500,  G 

14HR . J.  HARRISON, 24HDOE/Sandia  National  Labs ,4,0;  G 

228  101  250  0 0 000000101D 
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B - 48 


228 

0 

0 

1 

0 

FCF  INFO  ID 

2 

212 

2 

0 

1 

250 

0 

0 

000010101D 

3 

212 

0 

0 

5 

0 

FCF  TEXT  ID 

4 

106 

7 

0 

1 

250 

0 

0 

000010101D 

5 

106 

0 

0 

2 

63 

FCF  BOX  ID 

6 

110 

9 

0 

1 

250 

0 

0 

000010101D 

7 

110 

0 

0 

1 

0 

FCF  SEP  ID 

8 

110 

10 

0 

1 

250 

0 

0 

000010101D 

9 

110 

0 

0 

1 

0 

FCF  SEP  2D 

10 

110 

11 

0 

1 

250 

0 

0 

000010101D 

11 

110 

0 

0 

1 

0 

FCF  SEP  3D 

12 

228.3.4.5.7.9.11.0. 0; 

212.4.1.0. 4167.0.5000. 1001 .1.5708.0. 0000 .0.0.5.2500.5.1500, 
0.0000, lHj ,6,3.5000,0.5000,1001,1.5708,0.0000,0,0,6.2500, 

5. 1500.0.  0000. 6Hn0. 25m, 1,0. 5000, 0.5000, 1,1. 5708, 0.0000, 0,0, 

10. 2500. 5. 1500.0.  0000. 1HB, 2, 1.2500, 0.5000, 1001, 1.5708, 

0 . 0000 ,0,0,11.2500,5. 1500 , 0 . 0000 , 2HCm ,0,0; 

106.1.4.0. 0000.5.0000.5.8000.12.7500.5.8000.12.7500.5.0000, 

5.0000. 5.0000.0.0; 

110.6. 0000 .  5 . 8000 . 0 . 0000 . 6 . 0000 . 5 . 0000 . 0 . 0000 .0.0; 

110 . 10 . 0000 .  5 . 8000 . 0 . 0000 . 10 . 0000 . 5 . 0000 . 0 . 0000 .0.0; 

110 . 11 . 0000 .  5 . 8000 . 0 . 0000 . 11 . 0000 . 5 . 0000 . 0 . 0000 .0.0; 

S 48G  3D  12P  11 


IP 

3P 

3P 

3P 

3P 

3P 

5P 

5P 

7P 

9P 

IIP 
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B 


49 


s 

F FCFTC06  S 

DAT  S 

S 

V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  11  IS 

110  0 4 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #6 . S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000066666 , 11HFCFTC06 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000066666, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 12. 5000,  G 

14HR . J.  HARRISON, 24HD0E/Sandia  National  Labs, 4,0;  G 

228  1 0 1 250  0 0 000000101D 
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B - 50 
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0 

FCF  INFO  ID 

212 
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0 
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0 

0 000010101D 

212 
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0 

FCF  TEXT  ID 

106 

8 
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1 

250 

0 

0 000010101D 

106 

0 
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63 

FCF  BOX  ID 

110 

10 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  ID 

110 

11 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  2D 

110 

12 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  3D 

110 

13 

0 

1 

250 

0 

0 000010101D 

110 

0 

0 

1 

0 

FCF  SEP  4D 

228,3,5,5,7,9,11,13,0;  IP 


212.5.1.0. 4167.0. 5000 . 1001 .1.5708.0.0000.0.0.5.2500.5.1500,  3P 

0 . 0000 , lHj , 5 , 3 . 0000 , 0 . 5000 , 1001 , 1 . 5708 , 0 . 0000 ,0,0,6.2500,  3P 

5. 1500.0.  0000. 5HnO. 4m, 1,0. 5000, 0.5000, 1,1. 5708, 0.0000, 0,0,  3P 

9 . 7500 . 5 . 1500 . 0 .  0000 . 1HF, 1,0. 5000 , 0 . 5000 ,1,1.5708,0. 0000 , 0 , 3P 

0,10.7500,5. 1500 , 0 . 0000 , 1HE ,1,0. 5000 , 0 . 5000 ,1,1.5708,0. 0000 , 3P 

0,0,11.7500,5. 1500 , 0 . 0000 , 1HD ,0,0;  3P 

106.1.4.0. 0000.5.0000.5.8000.12.5000.5.8000.12.5000.5.0000,  5P 

5.0000. 5.0000.0.0;  5P 

110.6. 0000 .  5 . 8000 . 0 . 0000 . 6 . 0000 . 5 . 0000 . 0 . 0000 .0.0;  7P 

110.9. 5000 . 5 . 8000 . 0 .  0000 . 9 . 5000 . 5 . 0000 . 0 . 0000 .0.0;  9P 

110 . 10 . 5000 . 5 . 8000 . 0 .  0000 . 10 . 5000 . 5 . 0000 . 0 . 0000 .0.0;  IIP 

110 . 11 . 5000 . 5 . 8000 . 0 .  0000 . 11 . 5000 . 5 . 0000 . 0 . 0000 .0.0;  13P 

S 48G  3D  14P  13  T 


s 

F FCFTC07  S 

DAT  S 

S 

V IGES  3.0  s 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 3 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #7.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000077777 , 11HFCFTC07 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000077777, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 15. 7500,  G 

14HR . J.  HARRISON, 2 4HD0E/ Sand 1 a National  Labs, 4,0;  G 

228  1 0 1 250  0 0 000000101D 
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B - 52 
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0 

FCF  ; 

INFO 

ID 

212 

2 

0 

1 

250 

0 

0 

000010101D 

212 
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FCF  TEXT 

ID 

106 
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250 

0 

0 

000010101D 

106 
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63 

FCF_ 

BOX 

ID 

110 
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250 
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000010101D 

110 
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FCF_ 

SEP 

ID 

110 

10 
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250 
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000010101D 

110 
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0 

1 

0 

FCF_ 

SEP 

2D 

110 

11 

0 

1 

250 

0 

0 

000010101D 

110 

0 

0 

1 

0 

FCF 

SEP 

3D 

228,3,4,5,7,9,11,0,0,0;  IP 


212.4.1.1.0000. 0.5000.1001.1.5708.0.0000.0.0.5.2500.5.1500,  3P 

0 . 0000 , 1H- , 11 , 6 . 0000 , 0 . 5000 , 1001 ,1.5708,0. 0000 ,0,0,6. 7500 , 3P 

5 . 1500 . 0 .  0000 . 11HnO .005/0.10,1,0. 5000 , 0 . 5000 ,1,1. 5708 , 0 . 0000 , 3P 

0, 0, 13. 2500, 5. 1500,0. 0000, 1HA, 2, 1.2500, 0.5000, 1001, 1.5708,  3P 

0 . 0000 ,0,0,14. 2500 , 5 . 1500 , 0 . 0000 , 2HBm, 0 , 0 ; 3P 

106.1.4.0. 0000.5.0000.5.8000.15.7500.5.8000.15.7500.5.0000,  5P 

5.0000. 5.0000.0.0;  5P 

110.6. 5000 . 5 . 8000 . 0 .  0000 . 6 . 5000 . 5 . 0000 . 0 . 0000 .0.0;  7P 

110 . 13 . 0000 .  5 . 8000 . 0 . 0000 . 13 . 0000 . 5 . 0000 . 0 . 0000 .0.0;  9P 

110 . 14 . 0000 .  5 . 8000 . 0 . 0000 . 14 . 0000 . 5 . 0000 . 0 . 0000 .0.0;  IIP 

S 48G  3D  12P  11  T 


s 

F FCFTC08  S 

DAT  S 

S 

V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 2 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #8.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb=1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000088888 , 11HFCFTC08 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000088888, 1.0,1 ,4HINCH, 8, 0.08, 13H880224. 140500, 0.0001, 15. 0000,  G 

14HR . J.  HARRISON, 24HD0E/Sandia  National  Labs, 4,0;  G 

228  1 0 1 250  0 0 000000101D 
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B - 54 
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INFO 

ID 
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212 
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TEXT 
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_SEP 
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228,3,3,5 

,7,9, 

0,0,0; 

IP 

1 

212,3,1,0 

.5547 

,0.5000,1001,1.5708,0 

.0000,0,0,5.2500,5 

1500, 

3P 

2 

0 . 0000 , lHc ,13,7. 0000 

, 0 . 5000 ,1,1. 5708 , 0 . 0000 ,0,0,6. 7500 , 

3P 

3 

5.1500,0. 

0000 , 13H0 . 005/0 . 1X0 . 1 , 1 , 0 . 

5000,0.5000,1,1.5708, 

3P 

4 

0.0000,0, 

0,14. 

2500,5 

.1500,0.0000, 1HA, 0,0; 

3P 

5 

106,1,4,0 

.0000 

, 5 . 0000 , 5 . 8000 , 15 . 0000 , 5 . 8000 , 15 . 0000 , 5 

0000, 

5P 

6 

5.0000,5. 

0000,0,0; 

5P 

7 

110,6.5000,5.8000,0. 

0000 , 6 . 5000 , 5 . 0000 , 0 . 0000 ,0,0; 

7P 

8 

110,14.0000,5. 

8000,0 

.0000,14.0000,5 

.0000,0.0000,0,0; 

9P 

9 

S 48G 

3D 

10P  9 

T 

1 

B - 55 


s 

F FCFTC09  S 

DAT  S 

S 

V IGES  3.0  s 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM  COUNT  S 

228  0 IS 

212  0 IS 

106  63  IS 

110  0 3 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #9.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 

S 

H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 

S 

L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

1H , , 1H ; , 10H0000099999 , 11HFCFTC09 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G 

10H0000099999, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 14. 2500,  G 

14HR . J.  HARRISON, 24HD0E/Sandia  National  Labs, 4,0;  G 

228  1 0 1 250  0 0 000000101D 
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F FCFTC10  S 

DAT  S 
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V IGES  3.0  S 

S 

I Application  Protocol  Test  Case  S 

Application  Protocol:  Drafting  S 

Information:  Feature  Control  Frames  S 

S 

E ENTITY  FORM,  COUNT  S 

228  0 IS 

212  0 IS 

106  63  3 S 

110  0 4 S 

S 

B This  is  a test  case  for  the  Feature  Control  Frames  Application  S 

Protocol  example.  This  test  case  implements  the  Feature  Control  S 

Frame  shown  in  Figure  B5  and  labeled  as  FCF  #10.  S 

S 

P Not  applicable  S 

S 

R Not  applicable  S 

S 

C This  test  case  was  prepared  as  per  the  IGES  Test  Case  Development  S 

Committee's  "Guide  to  Developing  Entity  Test  Cases",  S 

Draft  Version  0.2,  November  10,  1987.  S 

S 

D IGES  Specification,  Version  3.0  S 

Guidelines  for  the  Specification  and  Validation  of  IGES  Application  S 
Protocols,  Draft  Version  0.04  S 
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H 24-Feb-1988  A Created  Test  Case  for  AP  Example  - R.J.  Harrison  S 
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L This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  that  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

product,  process,  or  service  by  trade  name,  trademark,  S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 
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